Reconocimiento automático de trazos on

Ingeniería Informática
Sistemas Informáticos (II31)
Reconocimiento automático de trazos on-line aplicado
al prototipado rápido de interfaces grácas de usuario
Esta 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 trazos
on-line aplicado al reconocimiento de elementos de interfaces grácas de usuario (widgets ) desarrollando así una aplicación que permite el prototipado rápido de este tipo de interfaces mediante
el reconocimiento automático de formas.
Dado que el reconocedor es usado a través de una aplicación de prototipado de interfaces, se
comienza 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 del
cuestionario, la observación y las entrevistas personales a los participantes en esta fase previa a
la 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. Se
comentan algunas de las alternativas encontradas y se justica la elección de un reconocedor que,
si bien por sí solo no es capaz de dar soporte a todos los requisitos anteriores, combinado con
dos estrategias independientes sí que permite cumplir con todos ellos. Estas dos estrategias son,
por un lado, la estrategia de la doble clasicación por la que varias clases se clasican como si
todas ellas fueran la misma, lo que permite que un reconocedor en principio sensible al escalado
y a la orientación pase a ser insensible a estas dos características; por otro lado, la estrategia
de usar el reconocedor de trazos como parte de un sistema de reconocimiento de widgets más
complejo que, partiendo de los trazos clasicados por el reconocedor de trazos y haciendo uso
de relaciones geométricas entre otros trazos previamente reconocidos es capaz de emular a un
reconocedor multitrazo.
Se termina la memoria presentando la aplicación desarrollada y su funcionamiento, así como
las conclusiones del proyecto y algunas sugerencias para posibles extensiones del mismo a realizar
en un futuro.
Palabras clave
Reconocimiento de formas. Pen computing. Análisis de requisitos. Diseño de interfaces grácas
de usuario.
Agradecimientos
Agradezco a mi director de proyecto, el profesor Vicente Javier Traver Roig, toda la ayuda
prestada durante la realización de este proyecto, en especial la enorme paciencia que ha tenido
conmigo.
También deseo dar las gracias a tod[oa]s l[oa]s compañer[oa]s y amig[oa]s que participaron
en la fase de análisis de requisitos, ya que sin sus aportaciones no hubiera sido posible darle a
este 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 . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.
Motivación para la realización del proyecto . . . . . . . . . . . . . . . . . . . . . .
1
1.3.
Planicación temporal estimada para el proyecto
. . . . . . . . . . . . . . . . . .
2
1.4.
Cronograma de la realización del proyecto
. . . . . . . . . . . . . . . . . . . . . .
10
2. Análisis de los requisitos esperados para el proyecto
2.1.
Introducción al análisis de requisitos
2.2.
Análisis de los requisitos para el reconocedor de widgets
17
. . . . . . . . . . . . . .
17
2.2.1.
Elección de los widgets a ser representados . . . . . . . . . . . . . . . . . .
17
2.2.2.
Descripción del cuestionario para la elección de la representación gráca
más intutitiva para cada widget . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2.3.
Resultados del cuestionario referentes al dibujado de los widgets . . . . . .
21
2.2.4.
Investigación del dibujado de la representacion gráca más intuitiva para
cada widget
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Listado de requisitos del reconocedor de widgets . . . . . . . . . . . . . . .
40
Análisis de los requisitos para la aplicación . . . . . . . . . . . . . . . . . . . . . .
41
2.2.5.
2.3.
17
. . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1.
Análisis de los requisitos de la aplicación obtenidos mediante el cuestionario 42
2.3.2.
Análisis de los requisitos de la aplicación obtenidos mediante la entrevista
2.3.3.
a los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
Listado de requisitos de la aplicación reconocedora
45
. . . . . . . . . . . . .
3. El reconocedor de trazos
47
3.1.
Denición del problema del reconocimiento de trazos . . . . . . . . . . . . . . . .
47
3.2.
Elección del algoritmo de reconocimiento de trazos
. . . . . . . . . . . . . . . . .
48
3.2.1.
Algunas de las técnicas usadas en el reconocimiento de formas . . . . . . .
48
3.2.2.
Justicación del algoritmo reconocedor y estrategia de embellecido elegidas
52
3.3.
3.4.
Descripción del algoritmo de reconocimiento de trazos elegido . . . . . . . . . . .
53
3.3.1.
Descripción general del algoritmo . . . . . . . . . . . . . . . . . . . . . . .
53
3.3.2.
Descripción del caracterizador . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.3.3.
Descripción del entrenador . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.3.4.
Descripción del clasicador
. . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.3.5.
Descripción del rechazador . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Comentarios sobre el diseño e implementación del algoritmo de reconocimiento de
trazos
3.4.1.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estrategia de la doble clasicación
vii
. . . . . . . . . . . . . . . . . . . . . .
61
62
viii
4. El reconocedor de
4.1.
4.2.
widgets
65
Motivación de un reconocedor de widgets separado del de trazos . . . . . . . . . .
65
Funcionamiento del reconocedor de widgets
65
. . . . . . . . . . . . . . . . . . . . .
4.2.1.
Relaciones posibles entre dos elementos
. . . . . . . . . . . . . . . . . . .
66
4.2.2.
Reglas de deniciones de los widgets
4.2.3.
Funcionamiento del algoritmo reconocedor de widgets
. . . . . . . . . . . . . . . . . . . . .
67
. . . . . . . . . . .
68
4.3.
Organización del código del reconocedor de widgets . . . . . . . . . . . . . . . . .
70
4.4.
Reglas de reconocimiento de widgets usadas por la aplicación del proyecto
71
. . . .
5. Las aplicaciones desarrolladas
5.1.
5.2.
5.3.
75
Descripción general de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Descripción del entorno gráco del entrenador . . . . . . . . . . . . . . . . . . . .
75
5.2.1.
Funcionalidades de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.2.2.
Detalles de implementación
. . . . . . . . . . . . . . . . . . . . . . . . . .
77
Descripción de la aplicación de diseño de interfaces . . . . . . . . . . . . . . . . .
78
5.3.1.
Funcionalidades de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.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 la
aplicación
C. Ejemplo de código generado por la aplicación
93
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ón
que capturase y reconociese lo que el usuario dibujase a mano alzada, bien con una tableta
digitalizadora o con otro dispositivo apuntador, y que la información adquirida por este medio
se aplicase en un contexto determinado. Esto daba mucha exibilidad para adaptar el proyecto
a las inquietudes del proyectando por lo que se procedió a determinar un alcance concreto para
el 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 desarrollar
una aplicación que reconociese elementos de interfaces grácas de usuario (de ahora en adelante
llamados 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 en
determinadas fases de desarrollo del proyecto, especialmente en la fase de análisis de necesidades
y, 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 el
desarrollo de una aplicación que permitiese la interacción del proyectando con los posibles futuros
usuarios de la misma. Este enfoque daba mucha importancia al análisis de requisitos, un tema
muy atrayente para el proyectando y al que se le dio mucha importancia durante el desarrollo
del proyecto, dedicando mucho tiempo tanto a investigar en la bibliografía como a la práctica de
diversas 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 en
concreto fue la exploración de la disciplina del reconocimiento de trazos, de la que el proyectando
no tenía conocimiento alguno. La realización de este proyecto permitía obtener una visión general
del estado del arte en cuanto al reconocimiento de trazos, así como la inspección de varios de los
algoritmos propuestos para resolver este problema y la programación y la experimentación con
alguno de ellos.
Además de las motivaciones anteriores, puramente académicas, se tenía también la motivación de tal vez llegar a realizar alguna aplicación de desarrollo rápido de interfaces que pudiera
ser utilizada tanto en un entorno profesional (ayudando a los diseñadores de aplicaciones y especialistas en usabilidad de las mismas a generar prototipos de interfaces grácas de usuario de
forma rápida, ahorrando así costes en los proyectos) como en un entorno académico (permien1
2
CAPÍTULO 1.
INTRODUCCIÓN
tiendo a los estudiantes de asignaturas relacionadas con el diseño centrado en los usuarios crear
prototipos de interfaces grácas rápidamente, centrándose en los aspectos de usabilidad más que
en 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 visual basadas en arrastrar y soltar elementos desde una paleta, aunque también es cierto que
presentan ciertos inconvenientes frente a éstas. Entre las ventajas de aplicaciones como la descrita en esta memoria cabe destacar un modo más natural para el diseñador de interfaces de
realizar un diseño de las mismas, así como una mayor velocidad en cuanto a la realización de
los primeros diseños de la interfaz en los que una primera idea de cómo quedaría la misma es
más importante que el centrarse en los detalles de situación de los elementos e interacción entre
ellos. El hecho de permitir especicar un diseño mediante un dibujado del mismo puede también
animar a los usuarios nales a perder el miedo a implicarse en la fase de diseño, incitando a éstos
a colaborar activamente en el desarrollo de la interfaz de la aplicación una vez superado el corto
periodo de aprendizaje de una herramienta de diseño como la mostrada en esta memoria. Este
periodo de aprendizaje se presupone, además, más corto que el de una herramienta de desarrollo
visual clásica. Entre las desventajas más evidentes de aplicaciones como las de este proyecto se
encuentra la dicultad de desarrollar una interfaz muy compleja con elementos anidados (por
ejemplo, un marco con elementos en su interior) y la limitación de la complejidad de los eventos
que pueden asociarse a cada widget, algo para lo que debe escribirse código si se quiere indicar
un comportamiento complejo para la aplicación a ser diseñada.
1.3.
Planicación temporal estimada para el proyecto
Las Figuras 1.1 (p. 8) y 1.2 (p. 9) muestran la planicación temporal, en forma de diagrama de
Gantt, que inicialmente se hizo para el proyecto. Se prerió no hacer una estimación del número
de horas para cada día puesto que debido a la compaginación de la realización del proyecto con la
asistencia a varias asignaturas por parte del proyectando, la realización de la estancia en prácticas
por parte de éste y demás imprevistos iban a hacer inútil cualquier previsión de número de horas
asignada a cada tarea. Por lo tanto, la planicación se realizó más con criterios orientativos y de
guí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 denió antes de comenzar el proyecto,
realizada el 14 de octubre de 2007, también más con nes orientativos que con ánimo de controlar
la realización de las mismas en un futuro. Se citan a continuación los objetivos que se pretendían
alcanzar 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 estado
del arte en cuanto a reconocimiento de trazos dibujados a mano, así como encontrar
diversos algoritmos que sirvan para este propósito. Se determinará qué algoritmos
de todos los encontrados resultan más efectivo para el trabajo del proyecto, para ser
evaluados 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 pretende
recopilar 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 los
usuarios.
◦ Tarea 1.2.2:
Técnicas de prototipado: Se pretende recopilar técnicas de prototipado para
usarlas en tareas posteriores del proyecto en las que haya que realizar prototipos
de 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 usuarios. Esta tarea de revisión bibliográca está muy desplazada en el calendario
porque su realización dependerá de que se haya terminado a tiempo la aplicación (antes de la fecha límite del 21 de febrero de 2008) para poder realizar una
evaluació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 previamente preparadas, para ser entregado en papel a los usuarios que vayan a cumplimentarlo. El objetivo del cuestionario será hacer un perl general de usuarios
que previamente hayan diseñado una interfaz gráca en papel, recopilando infromació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 los
usuarios 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 para
un 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 preguntas
previamente preparadas, para ser entregado en papel a los usuarios que vayan
a cumplimentarlo. El objetivo principal del cuestionario será determinar cuál
es la representación gráca que los usuarios tienen en mente sobre los widgets
que 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:
4
CAPÍTULO 1.
INTRODUCCIÓN
Tarea 2.2.2.1:
Preparación: Se preparará una pequeña aplicación en la que los usuarios
puedan dibujar los widgets que se descubra que sean más necesarios a la hora
de diseñar una aplicación.
Tarea 2.2.2.2:
Realización: Se le pedirá a los usuarios dibujar los widgets de la forma
que previamente se haya derivado de la tarea 2.2.1.3. Posteriormente se le
permitirá 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.2.3:
Análisis de resultados: Igual que la tarea 2.1.3.
◦ 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 preguntas
previamente preparadas, para ser entregado en papel a los usuarios que vayan
a cumplimentarlo. El objetivo principal del cuestionario será determinar si
los usuarios reconocen a simple vista qué widgets representan los trazos que
hicieron otros participantes en la tarea 2.2.2.2. Se espera que los usuarios los
reconozcan sin problemas.
Tarea 2.2.3.2:
Cumplimentación por parte de los usuarios: Igual que la tarea 2.1.2.
Tarea 2.2.3.3:
Análisis de resultados: Igual que la tarea 2.1.3.
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 durante la entrevista con los usuarios. Las preguntas estarán orientadas a capturar requisitos que deba cumplir la aplicación a desarrollar.
Tarea 3.1.1.1:
Realización: Se pretende realizar estas entrevistas de forma presencial, con
preferencia individual, aunque no se descarta hacerlas en grupos de pocas
personas (hasta un máximo de tres entrevistados). También es posible que
deban realizarse por teléfono o correo electrónico en aquellos casos en los que
no quede más remedio.
Tarea 3.1.1.1:
Análisis de resultados: Igual que la tarea 2.1.3.
◦ Tarea 3.1.2:
Desarrollo de diseños candidatos: Diseño de prototipos de baja delidad de
la aplicación, atendiendo a las conclusiones resultantes de la tarea 3.1.1.1.
1.3.
PLANIFICACIÓN TEMPORAL ESTIMADA PARA EL PROYECTO
5
◦ 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 durante la entrevista con los usuarios. Las preguntas estarán orientadas a determinar un diseño nal de entre todos los candidatos resultado de la tarea
3.1.2., bien por eliminación de todos excepto de uno, bien por fusión de las
mejoras presentes en cada uno de ellos.
Tarea 3.1.3.2:
Realización: Se pretende realizar estas entrevistas de forma presencial, con
preferencia individual, aunque no se descarta hacerlas en grupos de pocas
personas (hasta un máximo de tres entrevistados).
Tarea 3.1.3.3:
Análisis de resultados: Igual que la tarea 2.1.3.
◦ Tarea 3.1.4:
Desarrollo del diseño nal: Se diseñará la interfaz resultante de analizar las
necesidades descubiertas en la tarea 3.1.3.
◦ Tarea 3.1.5:
Tercera entrevista: conrmación o mejora del diseño nal:
Tarea 3.1.5.1:
Preparación: Se confeccionará un listado de preguntas a ser realizadas durante la entrevista con los usuarios. Las preguntas estarán orientadas a conrmar que el diseño de la interfaz resultante de la tarea 3.1.4. es lo que los
usuarios esperaban. Se ajustarán los posibles errores que se hayan cometido
en el diseño debido a un mal entendimiento.
Tarea 3.1.5.1:
Realización: Se pretende realizar estas entrevistas de forma presencial, con
preferencia individual, aunque no se descarta hacerlas en grupos de pocas
personas (hasta un máximo de tres entrevistados).
Tarea 3.1.5.1:
Análisis de resultados: Igual que la tarea 2.1.3.
• 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 del
lenguaje vendrá determinada por el sistema operativo en que trabajen los usuarios, (aunque se intentará que el lenguaje sea multiplataforma), y por la existencia
de librerías adecuadas para el desarrollo de la interfaz gráca y el reconocimieto
de patrones.
◦ Tarea 3.2.2:
Modelado del código de la aplicación: Se realizará un diagrama de clases
en UML de la aplicación a desarrollar, siempre y cuando la complejidad de la
aplicación así lo requiera. En caso de que ésta no sea muy compleja únicamente
se describirán las clases a implementar y sus interfaces.
◦ Tarea 3.2.3:
Programación del algoritmo de reconocimiento:
Tarea 3.2.3.1:
6
CAPÍTULO 1.
INTRODUCCIÓN
Programación de algoritmos candidatos: Se implementarán los algoritmos seleccionados en la tarea 1.1.
Tarea 3.2.3.2:
Segunda observación: evaluación de los algoritmos de reconocimiento: Se pedirá a los usuarios que dibujen los widgets para evaluar qué algoritmo
los 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 en
solitario.
◦ Tarea 3.2.4:
Programación de la interfaz gráca de usuario: Se programará la interfaz
de usuario diseñada en la tarea 3.1.
◦ Tarea 3.2.5:
Integración de algoritmo de reconocimiento e interfaz de usuario: Se
integrará en una sóla aplicación el reconocedor de trazos desarrollado en la tarea
3.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 un
grupo de estudiantes de la asignatura Entornos de Usuario impartida en la universidad del proyectando para que, si quieren, la evalúen y comenten los aspectos
mejorables 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 mejoras
detectadas 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 implementar las tareas más prioritarias y se seguirá por aquellas menos prioritarias
segú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
1.3.
PLANIFICACIÓN TEMPORAL ESTIMADA PARA EL PROYECTO
7
análisis que permita dirigir las tareas a realizar por cualquiera que desee continuar
con el proyecto una vez reabierto éste. Las mejoras que se deduzcan de esta
segunda evaluación no se implementarán.
Tarea 5:
Desarrollo de la memoria del proyecto: Se escribirá la memoria del proyecto, usando
como 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 transparencias
a 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 lugar
indicado.
CAPÍTULO 1.
Figura 1.1: Primera página del cronograma estimado para el proyecto, cuyas tareas se describen en la Sección 1.3.
8
INTRODUCCIÓN
PLANIFICACIÓN TEMPORAL ESTIMADA PARA EL PROYECTO
Figura 1.2: Segunda página del cronograma estimado para el proyecto, cuyas tareas se describen en la Sección 1.3.
1.3.
9
10
CAPÍTULO 1.
1.4.
INTRODUCCIÓN
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 la
terminación del proyecto. Algunas de esta tareas coinciden con las previstas inicialmente para el
proyecto (ver la Sección 1.3) y otras son modicaciones o fusiones de algunas que inicialmente
se previeron pero que nalmente fueron alteradas.
En el listado de tareas siguiente se comenta brevemente en qué consistió cada tarea y, de
proceder, 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 de
artículos relacionados con el reconocimiento de trazos (pattern recognition) y la
computación usando como dispositivo de interacción el bolígrafo sobre una supercie
táctil (pen computing) con la nalidad de seleccionar, una vez realizado el análisis
de requisitos, el algoritmo reconocedor más apropiado, así como familiarizarse con el
estado del arte de la disciplina del pen computing. El resultado de esta búsqueda se
encuentra 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álisis de requisitos: Se realizó una búsqueda en la bibliografía dedicada a la interacción
persona-ordenador (HCI de Human-Computer Interaction ) dedicada a investigar sobre
las técnicas de recogidas de información para determinar los requisitos que debía tener
el proyecto. En concreto, se buscó información referente a la realización de cuestionarios, de entrevistas y de observaciones de usuarios. Todo esto permitió la realización
del 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 cuestionario
tuvo como objetivo descubrir ciertos requisitos de la aplicación que iba a hacer uso del
reconocedor (estos requisitos se describen en la Sección 2.3.1, p. 42) y de determinar
qué representación tenían en mente los posibles futuros usuarios de la aplicación a
desarrollar (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 recomendaciones 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 a
posibles diseñadores de intefaces de usuario con las indicaciones oportundas para
su correcta devolución.
◦ Tarea 2.1.3:
Análisis de resultados: Una vez terminado el plazo para la entrega del cuestionario se procedió a analizar los resultados para obtener las conclusiones. Este
proceso se describe en la Sección 2.2.3 (p.21).
1.4.
11
CRONOGRAMA DE LA REALIZACIÓN DEL PROYECTO
• Tarea 2.2:
Primera observación: determinar un dibujo para los
widgets
elegidos: Una
vez se supo cuál era la representación más común de los mismos gracias al cuestionario
de la tarea 2.1 se tuvo que averiguar cómo se dibujaban éstos usando el dispositivo
apuntador que, de acuerdo con el análisis de requisitos, era el más utilizado por los
participantes en el estudio.
◦ Tarea 2.2.1:
Preparación: Se optó por una observación no invasiva de los usuarios para lo
cual 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 widgets
y posteriormente ser visualizadas tantas veces como fuera necesario sin estar ellos
presentes.
◦ Tarea 2.2.2:
Realización: Se les pidió a los participantes en el estudio que dibujasen, con
ayuda de una de las dos aplicaciones desarrolladas, llamada Pizarra, las representaciones que se habían deducido para cada widget.
◦ Tarea 2.2.3:
Análisis de resultados: Con ayuda de la aplicación Visor desarrollada para
la visualización de los trazos dibujados por los participantes en el estudio, se
determinó 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 la
aplicación: Para complementar el análisis de requisitos se decidió hacer una entrevista
a 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 preguntas
listadas el comienzo del Apéndice B.
◦ Tarea 3.1.2:
Realización: Se realizaron entrevistas de corta duración con aquellos diseñadores
que se ofrecieron a ello.
◦ Tarea 3.1.3:
Análisis de resultados: Una vez terminadas las entrevistas se analizaron las
respuestas 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 vino
determinada básicamente por la elección del lenguaje usado para programar el reconocedor. 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 desarrolló una primera versión del mismo sin prestar mucha atención al estilo de
12
CAPÍTULO 1.
INTRODUCCIÓN
programación ni a su reutilización, simplemente con la intención de comprobar si
el algoritmo elegido tenía las tasas de reconcimiento y la velocidad de ejecución
esperadas.
◦ Tarea 3.3.2:
Segunda observación: evaluación de algoritmo de reconocimiento: Una
vez programada una versión rápida del algoritmo de reconocimiento elegido éste
fue probado por el proyectando para comprobar que el mismo tenía las tasas de
reconocimiento y las velocidades de ejecución aceptables que se le habían presupuesto. En caso de no haber cumplido con estos requisitos se hubiera tomado la
decisió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 de
los trazos a partir de trazos de ejemplo. El algoritmo necesita, por lo tanto, de una
parte 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 aplicación Entrenador consiste fundamentalmente en la parte del reconocedor que realiza
el entrenamiento, aunque también incluye la parte del caracterizador para extraer
las características de los trazos que van a servir como entrenamiento. Estas dos
partes constituyen la mayor parte del reconocedor a desarrollar (ver el listado de
las partes del mismo en la Sección 3.3.1, p. 53) por lo que se desarrolló a la vez
todo 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 programa
con 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ólo
no basta para reconocer los widgets que se vio en el análisis de requisitos (Capítulo 2) que debía reconocer la aplicación. Para que ello fuera posible se desarrolló un
reconocedor que, haciendo uso del reconocedor de trazos (Capítulo 3), permitiera
reconocer 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 de
widgets es lo que permite un prototipado rápido de aplicaciones por medio del
dibujado de los widgets. Esto se consigue mediante la interfaz de la aplicación
HandStroke 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 denitiva para su evaluación de la presente memoria.
1.4.
CRONOGRAMA DE LA REALIZACIÓN DEL PROYECTO
13
• Tarea 4.2:
Corrección de la primera versión: Lectura de la memoria por parte del director
del 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 proyectando 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 del
proyecto descrito en la presente memoria.
describen en la Sección 1.4.
CAPÍTULO 1.
Figura 1.3: Primera página del cronograma que describe la distribución de las tareas realizadas para el mismo a lo largo del tiempo. Éstas se
14
INTRODUCCIÓN
describen en la Sección 1.4.
Figura 1.4: Segunda página del cronograma que describe la distribución de las tareas realizadas para el mismo a lo largo del tiempo. Éstas se
1.4.
CRONOGRAMA DE LA REALIZACIÓN DEL PROYECTO
15
16
CAPÍTULO 1.
INTRODUCCIÓN
Capítulo 2
Análisis de los requisitos esperados
para 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 el
desarrollo 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 interfaz
gráca.
Desde el punto de vista del software lo que estuvo claro desde el principio fue que el proyecto
iba a tener dos grandes componentes: el reconocedor de widgets y la aplicación que iba a servir
de interfaz entre dicho reconocedor y el usuario. Este capítulo describe en profundidad el proceso
de 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 Secció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ón
pudiera 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 clasicar a aquéllos más comunes. Una
vez elegidos éstos se determinó cuál era su representación gráca más intuitiva para la mayoría
de 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 resultado
la lista de requisitos de la Sección 2.2.5 para el reconocedor. Los Capítulos 3 y 4 describe el
reconocedor 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 encontrada
en la interfaz de una aplicación depende de la funcionalidad que quiera proporcionar ésta y del
conjunto que proporcione la librería de desarrollo de interfaces con la que haya sido desarrollada
la interfaz de la aplicación.
Para simplicar el desarrollo del proyecto se decidió que el reconocedor sólo reconociese un
conjunto 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 relativamente
fá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 claramente
poco comunes, propios de esa librería o que podían formarse a partir de la combinación de otros
widgets más sencillos (lo que permitiría añadirlos fácilmente posteriormente al conjunto de los
reconocidos por la aplicación en caso de tener tiempo). De este subconjunto se eligieron aquéllos
que, a criterio del proyectando, eran los más comunes en las interfaces grácas de la mayoría de
aplicaciones comerciales. También se tuvo en cuenta cuáles eran los widgets que los alumnos de
la asignatura Entornos de Usuario de la UJI del curso 2006/7 habían usado en su proyecto para
esa asignatura. Para ello se inspeccionó la memoria de 17 proyectos para determinár qué widgets
eran 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 el
calendario) o que podían formarse a partir de widgets más sencillos (las etiquetas, la caja de
texto 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 Entornos
de 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 mostrados
en 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 se
eligieron 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 de
diseñ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 determinar
los requisitos de la aplicación que iba a hacer uso del reconocedor. Estas cuestiones adicionales no
relacionadas con la forma de dibujar los widgets se detallan más adelante a partir de la Sección 2.3
y se adelanta aquí únicamente para dejar constancia de que se tuvo que preguntar un gran número
de 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, se
diseñó el cuestionario que se recoge en el Apéndice A, cuyos detalles de diseño y de recogida de
datos se comentan en profundidad a continuación.
Por claridad en la exposición se ha decidido comentar a continuación aquellos detalles del
cuestionario que son comunes tanto a la parte de adquisición de requisitos del reconocedor como
de la aplicación.
Se describe a continuación en detalle el cuestionario. Los resultados obtenidos en el cuestiona-
20
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
rio referentes al dibujado de los widgets se describen a partir de la Sección 2.2.3 (página 21. Los
resultados 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 los
cuales 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 dibujado
de los widgets eran todas de respuesta objetiva y no admitían distorsiones debidas a posibles
favoritismos por parte de los participantes, no se encontraron motivos para dudar de la abilidad
de las respuestas proporcionadas. La pregunta de dibujado de widgets tal vez tuvo sus respuestas
inuidas por los dibujos elegidos como ejemplo para cada widget, como se comenta más adelante
en 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 posibles
respuestas 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 decreciendo el nivel de optimismo hasta terminar con la más negativa. Se tomó la decisión opuesta a la
recomendada porque se supuso que la experiencia de los participantes rellenando cuestionarios
era mínima, y que la poca que pudieran haber tenido estaba marcada por los cuestionarios que
reparte periódicamente la universidad en la que estudian dichos estudiantes para evaluar al profesorado en los que las respuestas van precisamente en este orden no recomendado. Esto podría
considerarse una aplicación de la regla de la consistencia [PRE05, p. 354], denida para el diseño
de 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ón
diversas 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 los
estudiantes de la asignatura Entornos de Usuario en sus proyectos, atomicidad de los
widgets )
El listado de dispositivos apuntadores de la pregunta 2 se obtuvo de [WIK08], eliminando
1
aquéllos que eran claramente poco comunes (como el ratón de pie , la pantalla táctil o el
joystick, por ejemplo)
En la pregunta 3 se listaron los sistemas operativos que se observó que usan con más
frecuencia los estudiantes de Ingeniería en Informática de la universidad en la que estudia
el proyectando.
Las librerías de desarrollo de interfaces de usuario listadas en la pregunta 5 se obtuvieron
de la larga lista de [WXW08]. Por cuestiones de espacio en el cuestionario se eligieron
sólo unas pocas (las más comunes a juicio del proyectando), permitiéndole al usuario que
escribiese aquéllas otras que usase y que no estuvieran listadas.
1
http://en.wikipedia.org/wiki/Footmouse
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
21
Problemas manifestados por los participantes al cumplimentar el cuestionario
Al hacerles la entrega del cuestionario algunos pocos participantes se quejaron de la extensión en hojas del mismo. No pareció animarles el que en la segunda línea del cuestionario
se les indicaba que el tiempo de cumplimentación era de menos de 10 minutos. Unos pocos
usuarios, al ver por primera vez los tres párrafos iniciales del cuestionario en los que se
condensaba mucho texto, preguntaron directamente ¾qué tengo que hacer aquí?. Ésta
puede haber sido la explicación de que sólo el 44 % de los cuestionarios entregados fueran
devueltos.
Algunos usuarios comentaron que no se les había ocurrido otra forma de representar los
widgets que copiando las imágenes de los mismos que aparecían en el cuestionario a modo de
ejemplo, por lo que dichas imágenes pudieron haber sesgado las respuestas. Esta hipótesis
se vio reforzada por el hecho de que el undécimo widget que se pedía representar en el
cuestionario 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 se
pretendía que dibujaran), y no el que se indicaba con texto. Esto da una idea de la poca
importancia 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 del
cuestionario, (documentado anteriormente en la Sección 2.2.2), los errores listados a continuación
se encontraron una vez terminada la entrega del mismo (aunque ningún participante los hizo notar
durante el proceso):
En la pregunta 5, la última opción Puedo desarrollar una interfaz compleja, sin apenas
dicultades. debería haberse escrito como Puedo desarrollar una interfaz compleja, con
apenas dicultades.
El pie de página de la última pregunta comienza con Nunca será público [...]., reriéndose
a 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 usados
ya 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 del
cuestionario.
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éndice A que hacen referencia a la representación gráca de los widgets. Para la elección de la
representación de cada widget se ha optado por seguir el criterio de la mayoría de los participantes 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 la
aplicación permitiría reconocer varias representaciones diferentes para un mismo widget.
A continuación se muestran los dibujos que hicieron los quince participantes que entregaron
el cuestionario para representar los once widgets que aparecían en el mismo. Los resultados se
comentan también a continuación.
22
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Representación del
widget
barra de iconos
La Tabla 2.2 (página 22) muestra las quince
representaciones de este widget proporcionadas por los diseñadores. Todos ellos lo representaron
como un conjunto de elementos dispuestos horizontalmente dentro de lo que puede considerarse
un rectángulo horizontal y alargado. El tipo de elementos que se dibujaron dentro de este rectá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 de
iconos . 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/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 iconos
consiste en un rectángulo horizontal y alargado con cuadrados dispuestos en hilera horizontal en
su 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 quince
representaciones de este widget proporcionadas por los diseñadores. Su representación fue similar
a la del widget barra de iconos comentado anteriormente, diferenciándose de éste en el tipo
de elementos que se representaron dentro del rectángulo horizontal contenedor. La mayoría de
diseñ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
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
23
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 de
menú . 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)
ñ)
24
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
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 para
los 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 su
representación algún tipo de representación de texto. Viendo los dibujos de todos los widgets no
parece que hubiera un consenso claro sobre si la representación preferida era una línea horizontal
o bien una línea zigzageante de tipo horizontal. Durante las representaciones se ha optado por
esta ú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 catorce
de las quince representaciones se dibujó una sucesión de cuadrados dispuestos en hilera vertical
y en doce de estas catorce representaciones se optó por dibujar una línea de texto o algún tipo
de 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ón
múltiple de varias opciones consiste en una serie de cuadrados situados uno debajo del otro con
texto 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 las
quince representaciones de este widget proporcionadas por los diseñadores. Todos los diseñadores
optaron por dibujar una hilera vertical de círculos para representar cada opción del botón, y la
mayoría (trece de los participantes) optaron por dibujar texto o representaciones de texto a la
derecha de cada círculo para indicar el texto de cada opción.
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
Tabla 2.4:
Dibujos del tercer
widget
25
a representar en el cuestionario: los botones
de 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/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)
h)
i)
g)
j)
k)
m)
n)
l)
ñ)
En consecuencia se pensó que la representación gráca más natural de un botón de radio de
varias opciones consiste en una serie de círculos situados uno debajo del otro con texto al lado
de 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ñadores
representaron 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.
26
CAPÍTULO 2.
Tabla 2.5:
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Dibujos del cuarto
widget
a representar en el cuestionario: los botones
de 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/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)
m)
k)
n)
l)
ñ)
Figura 2.5: Representación gráca para el widget botones de radio.
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
Tabla 2.6:
Dibujos del quinto
widget
27
a representar en el cuestionario: el botón . 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/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 consiste
en un rectángulo horizontal no muy alargado con texto en su interior, tal y como muestra la
Figura 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) muestra
las quince representaciones de este widget proporcionadas por los diseñadores. Un diseñador (ver
la opción a de la tabla) se confundió y dibujó el widget de caja de entrada numérica con
incremento, por lo que su representación no se tuvo en cuenta para sacar conclusiones de este
widget.
28
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
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ás
popular (diez representaciones) que el triángulo (sólo tres representaciones), y casi siempre estuvo
separada del resto del interior del rectángulo por una línea vertical. Sólo cuatro diseñadores
dibujaron algún tipo de texto dentro del widget, y la mitad (cinco) lo dibujaron desplegado
mostrando sus opciones, la mayoría con texto dibujado dentro de la caja que representaba el
desplegable.
En consecuencia se pensó que la representación gráca más natural de una caja de selección
múltiple no desplegada consiste en un rectángulo horizontal no muy alargado con una cuña
apuntando hacia abajo situada en el interior del mismo, a la derecha y separada del resto del
interior del rectángulo por una línea vertical. La parte izquierda de la Figura 2.7 (p. 28) muestra
dicha representación.
Según lo visto, la representación gráca más natural de una caja de selección múltiple desplegada consiste el añadir a la representación de la misma no desplegada un rectángulo vertical
cuyo lado corto se comparte con la parte del lado largo del rectángulo del desplegable que no
contiene la cuña. En el interior del rectángulo vertical aparecen dibujadas líneas de texto. La
parte 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ón
de plegado (izquierda) y desplegado (derecha).
Representación del
widget
barra de desplazamiento
La Tabla 2.8 (página 30) muestra
las quince representaciones de este widget proporcionadas por los diseñadores. En doce de las
quince 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ángulo. En la mayoría de los casos las cuñas o triángulos estaban separadas del resto del interior
del rectángulo por una línea perpendicular al lado más largo de éste. En diez de las quince
representaciones se dibujó un elemento semejante a un rectángulo en el interior del rectángulo
contenedor.
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
Tabla 2.7:
Dibujos del sexto
widget
29
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/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)
m)
k)
l)
n)
ñ)
En consecuencia se pensó que la representación más natural de una barra de desplazamiento
consiste en un rectángulo alargado con una cuña en cada extremo apuntando hacia los lados
cortos del rectángulo más cercanos a éstas, con un rectángulo más pequeño y mucho menos
30
CAPÍTULO 2.
Tabla 2.8:
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Dibujos del séptimo
widget
a representar en el cuestionario: la barra de
desplazamiento . 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/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.
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
Representación del
widget
caja de entrada de texto
31
La Tabla 2.9 (página 32) muestra
las quince representaciones de este widget proporcionadas por los diseñadores. En todas las
representaciones menos una se optó por dibujar un rectángulo para representar la caja de entrada
de texto. En la mitad de los casos se dibujó algo dentro de la caja para indicar que se podía
escribir dentro de ella (un texto o una ralla vertical). No hubo consenso sobre si había que escribir
una etiqueta al lado de la caja: en siete de las quince representaciones se representó texto a la
izquierda de ésta, en una se puso el texto encima y en el resto se dibujó únicamente la caja de
entrada de texto.
Se decidió que la representación más natural de una caja de entrada de texto consiste en un
rectángulo alargado con una representación de texto fuera a su izquierda, tal y como muestra la
Figura 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 cada
representación fue diferente, por lo que se decidió extraer más la idea general que compartían
todas 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 clasicadora, dibujando un rectángulo, o curva rectangular, por cada pestaña, y situándolos todos sobre
un rectángulo mayor y que sirve de base común. La base de la pestaña seleccionada no existe
para que forme parte del rectángulo grande que sirve de base, y en la mayoría de los casos esta
pestañ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 en
un 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 lado
má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 de
más a la izquierda no tiene borde inferior para que así se una a la región inferior del rectángulo
contenedor. La Figura 2.10 clarica esta descripción.
Representación del
widget
deslizador
La Tabla 2.11 (página 35) muestra las quince
representaciones de este widget proporcionadas por los diseñadores. Trece de ellos optaron por
dibujar una línea a modo de carril, en unos pocos casos adornadas con marcas de escala, cortada
a su mitad por un rectángulo (en nueve de las trece representaciones) u otras guras. Este
rectángulo tenía su lado corto paralelo a la línea indicadora del carril del deslizador en la mayoría
de los casos.
En consecuencia se pensó que la representación más común de representar un deslizador
consiste en una línea recta cortada a su mitad por un rectángulo. La Figura 2.11 muestra esta
representación, en contra de los diseños mayoritarios y por despiste se dibujó este rectángulo de
modo que tuviera su lado largo paralelo a la línea recta.
32
CAPÍTULO 2.
Tabla 2.9:
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Dibujos del octavo
widget
a representar en el cuestionario: la caja de
entrada de texto . 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/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 entrada
de texto con selección lo que se corresponde con una caja de entrada de texto asociada a un
desplegable de modo que lo que se escribe está disponible como opción en sus futuros usos. No
obstante la imagen del widget de muestra mostraba el widget entrada numérica con incremento,
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
Tabla 2.10:
Dibujos del noveno
widget
33
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/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)
ñ)
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 diseñadores. Puede verse que doce de los quince participantes representaron el widget entrada
numérica con incremento, guiándose por el dibujo de muestra y no por la descripción textual
34
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
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 ellas
puede verse que se dibujó un rectángulo horizontal no muy largo, con dos cuñas o triángulos
en su interior, a su lado derecho apuntando en sentidos opuestos, una encima de la otra. En
la mayoría de las representaciones estos triángulos o cuñas estuvieron separadas del resto del
interior 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 con
incremento consiste en un rectángulo horizontal, no muy alargado, que está dividido por una
línea recta perpendicular a su lado más largo y que forma una zona pequeña a su derecha en la
que están dibujadas dos cuñas, situadas una encima de otra y apuntando en sentidos opuestos y
hacia 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 intuitiva
para cada widget
Una vez determinadas cuáles eran las representaciones más naturales para cada uno de los
widgets 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
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
Tabla 2.11:
Dibujos del décimo
widget
35
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/a
4, k) Usuario/a 14, l) Usuario/a 8, m) Usuario/a 5, n) Anónimo, ñ) Anónimo.
a)
b)
c)
f)
g)
h)
k)
l)
m)
d)
e)
i)
n)
j)
ñ)
la aplicación, ya que una búsqueda inicial entre la bibliografía había mostrado la ausencia del
reconocedor perfecto en cuanto a consumo de recursos y posibilidades de reconocimiento, como
se 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 se
pedía dibujarlos en el cuestionario requiriendo a los pidiéndoles a los participantes en el mismo que
dibujasen echas de dirección para cada trazo que dibujasen, numerando los distintos trazos de
36
CAPÍTULO 2.
Tabla 2.12:
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Dibujos del sexto
widget
a representar en el cuestionario: la entrada
numé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/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)
ñ)
cada gura en caso de que necesitasen más de uno para dibujarlo. Esta idea se descartó porque
complicaba la cumplimentación del cuestionario y podía sesgar los resultados al obligar a los
participantes 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 los
usuarios dibujasen libremente los widgets ; y otra aplicación, llamada Visor, que permitía visualizar
el modo en que los distintos usuarios habían dibujado cada widget. La razón de separar estas
dos aplicaciones fue que la aplicación Pizarra se desarrolló muy rápidamente para comenzar con
la captura de requisitos lo antes posible, por lo que las funcionalidades destinadas a Visor se
desarrollaron posteriormente y por separado para evitar tener que controlar las interacciones
entre ambos códigos y desarrollarlos a más velocidad. A continuación se explica cómo se realizó
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
37
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 con
una interfaz gráca desarrollada usando la librería TkInter. En la Figura 2.13 puede verse una
captura de dicha aplicación, llamada simplemente Pizarra. Ésta consistía básicamente en una
zona en la que cada participante podía dibujar los widgets que se había pedido representar en
el cuestionario descrito en la sección 2.2.2 (página 2.2.2). Para ello se escribía el nombre del
participante y se seleccionaba el widget a dibujar, y se daba el control del ratón (dado que éste
había sido el dispositivo apuntador utilizado por todos los participantes en el cuestionario, de
acuerdo con la gráca de uso de dispositivos de la Figura 2.17 (p. 43) al participante para que
2 para el widget seleccionado tiempo.
éste dibujase libremente la representación elegida
Figura 2.13: Captura de la aplicación Pizarra usada para que los usuarios pudieran dibujar las
representaciones de cada widget.
La 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.
2
38
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
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 excepcionalmente
algunos dibujaron una representación más. Hubo un participante que dibujó seis muestras de un
mismo widget, aunque todas ellas con la misma forma de dibujar el widget por lo que únicamente se consideraron tres. El número de representaciones de cada widget por cada participante se
puede 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 éste
terminaba de dibujar cada representación la guardaba mediante el botón de Guardar gura de
la aplicación, lo que hacía que se generase un chero conteniendo toda la información necesaria
para reproducir posteriormente, con ayuda de la aplicación Visor y sin ayuda del usuario, el
proceso 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 del
participante con 6 muestras del widget botón se indica entre paréntesis el número de ejemplos
que se consideraron.
Participantes
Widget
P1
P2
P3
P04
P5
P6
P7
P8
P9
P10
Barra de desplazamiento
3
3
3
3
3
3
3
3
3
3
Barra de iconos
3
3
3
3
4
3
3
3
3
3
Barra de menú
3
3
3
4
3
3
4
3
3
3
Botón
3
3
3
4
4
3
6(3)
3
3
3
Botones de radio
4
3
3
3
3
3
3
3
3
4
Botones de selección múltiple
3
3
3
3
3
3
3
3
3
3
Caja de entrada de texto
3
3
3
3
3
3
3
3
3
3
Caja de selección múltiple
2
3
3
3
4
3
3
3
3
3
Deslizador
3
3
3
3
4
3
4
3
3
3
Entrada numérica con incremento
4
3
3
3
3
3
4
3
3
3
Pestañas
3
3
3
3
3
3
3
3
3
3
Interpretación de los resultados obtenidos en la investigación sobre la forma de
dibujar cada representación de los
widgets
Como se comentó anteriormente, cuando un usuario decidía guardar la representación de un
widget realizada con el programa Pizarra, éste generaba un chero con la información necesaria
para reproducir de nuevo y sin intervención del usuario el dibujo generado por éste. Esto se
consiguió simplemente con la aplicación Visor, cuya captura de pantalla puede verse en la Figura 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 tal
cual lo pintó el usuario, con las mismas pausas entre cada trazo y la misma aceleración entre los
vértices consecutivos que componen cada uno de los trazos. Para facilitar la visualización de cada
representació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 para
la representación de los mismos, se llega a las siguientes conclusiones sobre la forma de dibujar
de los participantes en el estudio.
Conclusiones sobre la forma de dibujar los
widgets
2.2.
ANÁLISIS DE LOS REQUISITOS PARA EL RECONOCEDOR DE WIDGETS
39
Figura 2.14: Captura de la aplicación Visor usada para visualizar el modo en que los usuarios
dibujaron las representaciones de cada widget.
Hay consenso claro sobre la forma de dibujar aquellos widgets que contienen elementos en
su interior: se dibujan los elementos del dibujo de fuera hacia dentro. Primero se dibuja el
trazo 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 de
arriba abajo.
Las pestañas pueden dibujarse de la misma forma que los widgets contenedores: primero el
rectá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 botones
de radio. Algunos preeren 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; otros
preeren 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 el
texto 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 primero
el rectángulo y luego las líneas a sus lados, o bien primero la línea izquierda, luego el
rectángulo y luego la línea a su derecha, sin que ninguna de estas dos representaciones sea
mayoritaria. Una minoría opta por dibujar una línea alargada y posteriormente dibujar en
el centro de ésta el rectángulo que representa el deslizador, lo que desde luego no es la
representación dada como ejemplo a los usuarios (ver la Figura 2.11 (p. 34)
40
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
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) respectivamente) 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) se
dibujan casi siempre de izquierda a derecha, en un único trazo. Unos pocos participantes
lo 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 de
temblor varía de un participante a otro: algunos lo dibujan con zigzags más acusados y
otros 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, comenzando por arriba y en sentido antihorario.
La forma de cuadrado (Figura 2.15, parte (g)) se dibuja mayoritariamente con un único
trazo, comenzando por la esquina superior izquierda y siguiendo el sentido antihorario. Algunas personas lo dibujan a veces en sentido horario. Sólo una persona tenía por costumbre
dibujarlo en dos trazos.
La forma de rectángulo (Figura 2.15, parte (h)) se dibuja de muchas formas dependiendo
de 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 una
persona, 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, en
cuanto a número de personas que las usaron en alguna de sus representaciones, de mayor
a menor popularidad: a, b, d, e, j ; y f, h y k, éstos tres últimos igual de populares, con dos
personas cada uno, por lo que se decidió también despreciar dichas representaciones. Por
lo tanto, se consideró que las cinco formas principales de representar un rectángulo son las
de 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 cumplir
las 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 las
formas 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 la
Figura 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 deba
dibujar el segundo, por lo que pueden considerarse también representaciones de un único
trazo.
El reconocedor debe reconocer los widgets de la Sección 2.2.3, incluso aquéllos que estén
formados 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ña
menor 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 cuestionario
del Apéndice A para obtener respuestas a preguntas concretas que guiasen el desarrollo de la
aplicación y una entrevista personal para descubrir los requisitos más importantes de la aplicación
desde la subjetividad de los usuarios. El cuestionario fue devuelto por quince participantes y la
entrevista se realizó a ocho personas, la mayoría de las cuales habían completado el cuestionario
pero en cualquier caso todas ellas habían diseñado en algún momento de su vida al menos una
interfaz gráca.
En el cuestionario del Apéndice A descrito en la Sección 2.2.2 se incluyeron preguntas destinadas a determinar requisitos concretos del proyecto, tales como en qué entornos trabajaban
los usuarios, entendiendo por entorno el conjunto de sistema operativo y dispositivos apuntadores utilizados con mayor frecuencia. Se consideró necesario recopilar esta información para
determinar la elección del lenguaje sobre el que programar el reconocedor, así como las posibles
restricciones 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 era
generar código correspondiente a la implementación de la interfaz diseñada, se decidió preguntarles su experiencia con determinadas librerías de desarrollo de interfaces. Estos requisitos se
analizan a continuación.
La entrevista, cuyas preguntas y respuestas de todos los participantes se recogen en el Apéndice B, se realizó con el objetivo principal de analizar en detalle el proceso seguido por los
participantes para realizar una interfaz gráca. También para informarse de cuáles son las mayores dicultades encontradas en el desarrollo de las mismas, la experiencia de los participantes
con los programas de desarrollo visual y cuáles serían sus peticiones a un programa que ayudase
a realizar interfaces. Un análisis de las respuestas obtenidas en las entrevistas se encuentra en la
Sección 2.3.2.
La lista de los requisitos completos de la aplicación reconocedora, juntando los requisitos
obtenidos por medio del cuestionario con el de la entrevista, se encuentra en la Sección 2.3.3.
42
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Figura 2.16: Distintos representaciones de la gura rectángulo (Figura 2.15, opción (h)) realizadas por los participantes mediante la aplicación Pizarra. El punto indica el comienzo de cada
trazo 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 cuestionario
Con el objetivo de eliminar del estudio a aquellos participantes que no hubiesen diseñado
nunca ninguna interfaz, ya que se pensó que esto podía inuir a la hora de representar los
widgets en la pregunta primera del cuestionario, se les preguntó la experiencia de cada uno de
ellos diseñando interfaces de usuario. A la pregunta de cuántas interfaces grácas había diseñado
el encuestado, la mayoría de participantes (10 de 15) contestaron que sólo había diseñado de una
a tres. Cuatro declararon que habían hecho de 4 a 10, y sólo un participante respondió haber
hecho más de diez diseños. De todo esto se desprende que todos los participantes tenían una
cierta 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 el
cuestionario, seguido del touchpad, tal y como se deduce de los resultados mostrados por la
Figura 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 la
librería FLTK [SPI08]. El resto de librerías no tenían, ni de lejos, tanta popularidad entre los
participantes en el estudio. Este resultado sin duda se ha visto inuido por el hecho de haber
repartido el cuestionario entre estudiantes de informática de la UJI, donde el uso de la librería
FLTK se enseña en una asignatura del plan de estudios. La Figura 2.18 muestra los resultados
obtenidos en el cuestionario referentes a la pregunta del cuestionario: ¾Qué librerías de desarrollo
2.3.
ANÁLISIS DE LOS REQUISITOS PARA LA APLICACIÓN
43
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 la
pregunta ¾Sobre qué sistemas operativos trabajas habitualmente?.
2.3.2. Análisis de los requisitos de la aplicación obtenidos mediante la entrevista a los usuarios
El contenido de todas las ocho entrevistas pueden encontrarse en el Apéndice B. A continuación se realiza un resumen de las respuestas de los participantes que servirá para, en la
Secció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ñar
una interfaz. Éste solía hacerse con papel y lápiz, aunque un participante usaba el programa
Microsoft Paint para hacer los dibujos.
2. Cuatro de los seis que hacían uso de los diseños en papel los modicaban durante el proceso
de 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 sobre
los mismos para indicar el modo de cambiar de una ventana a otra dentro de la misma
aplicación, normalmente mediante el dibujado de echas desde el widget que provocaba el
cambio hasta la ventana destino (o bien un número indicando la ventana destino). Cuatro de
estos cinco además realizaban otras anotaciones sobre el dibujo de la interfaz comentando
el comportamiento de algún widget aislado.
44
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
Figura 2.18: Resultados obtenidos en la pregunta ¾Qué librerías de desarrollo de interfaces
usaste/has usado, y cuál es/fue tu experiencia con ellas? del cuestionario comentado en la
Sección 2.2.2
4. De los seis que desarrollaron prototipos grácos de las interfaces, cinco las usaron como
ayuda para renar la interfaz y hacerla más usable. Todos estos seis diseñadores utilizaron
estos diseños en papel como guía para implementar una interfaz lo más similar posible al
diseño realizado.
5. Para cuatro de los seis entrevistados la mayor dicultad en el desarrollo de la interfaz
consistió en la programación de la misma, bien por el lenguaje de programación o por el
uso de una librería de interfaces con la que tenían poca experiencia. Otras dicultades
consistieron en lograr una interfaz con un aspecto independiente de la resolución de la
pantalla y lograr una interfaz usable.
6. Quienes usaron un programa de desarrollo visual valoraron la facilidad de estos programas
para disponer los elementos en la pantalla, centrándose así más en el diseño y menos en
la programación. No obstante, sólo se valoraba este tipo de programas cuando el código
que desarrollaban era útil para ser modicado manualmente posteriormente por parte del
programador.
7. Las características que debería tener una aplicación para el desarrollo de interfaces grácas
son, considerando las opiniones de los seis entrevistados, las siguientes (en ningún orden
en particular):
a ) Debe ser fácil de usar.
b ) Debe disponer de una licencia GPL.
2.3.
ANÁLISIS DE LOS REQUISITOS PARA LA APLICACIÓN
45
Figura 2.19: Resultados obtenidos en la pregunta ¾Sobre qué sistemas operativos trabajas habitualmente? 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 calidad
y modicable por el programador si éste lo considera oportuno.
d ) Debe permitirle al programador modicar en cualquier momento aquellas cosas que se
hayan realizado por medio de la aplicación (disposición de los elementos, propiedades
de los mismos, código, etc.)
e ) El código de la interfaz generada debe ser independiente de la resolución del monitor
en la que ésta se visualice.
f ) Debe permitir denir de forma sencilla el comportamiento de los eventos asociados a
determinados 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 que
debe 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 dibujando
sobre un papel con un lápiz.
R2: Cada elemento del dibujo de la interfaz generado por medio de la aplicación debe dejar
clara su función.
R3: La aplicación debe permitir crear un storyboard, es decir indicar desde qué widget se
accede a qué ventana de las que componen la aplicación.
R4: La aplicación debe permitir modicar el diseño de la interfaz en cualquier momento.
46
CAPÍTULO 2.
ANÁLISIS DE LOS REQUISITOS ESPERADOS PARA EL PROYECTO
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 modicable por el programador.
R7: El código generado por la aplicación debe ser independiente de la resolución del monitor
en 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 cada
elemento de la interfaz diseñada.
R11: El dibujado del diseño de la interfaz debe ser posible por medio del ratón o del
touchpad.
R12: El código de la aplicación debe corresponder al lenguaje C++ y hacer uso de la
librerí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.
Denició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 muestra
el funcionamiento básico de un reconocedor de trazos: el reconocedor de trazos recibe como
entrada un trazo y éste es comparado con las distintas clases de trazos que es capaz de reconocer
el reconocedor. La salida del reconocedor es el tipo de la clase cuyo modelo de trazo es más
parecido al introducido, y la tarea principal del reconocedor consiste en calcular acertadamente
ese medida de similitud.
Figura 3.1: Funcionamiento básico de un reconocedor de trazos.
Los algoritmos de reconocimiento de trazos pueden clasicarse en dos tipos, de acuerdo con
la clasicación explicada por Junfeng Li [LI05]:
Reconocedores o-line : los dibujos a reconocer son convertidos en imágenes y posteriormente reconocidos mediante técnicas de reconocimiento de imágenes.
Reconocedores on-line : se dispone de información temporal y de presión sobre los puntos
que forman el dibujo. Este tipo de reconocedores pueden clasicarse en:
47
48
CAPÍTULO 3.
•
EL RECONOCEDOR DE TRAZOS
Asíncronos: El algoritmo no realiza un reconocimiento hasta que el usuario termina
de 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 aplicaciones
desarrolladas para el proyecto descrito en esta memoria pertenece a la categoría de reconocedor
on-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ño
de 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 del
arte de la disciplina del pen computing en la que se usa como dispositivo de interacción con el
ordenador algo semejante a un bolígrafo sobre una supercie táctil.
A continuación se hace un breve denició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 reconocimiento
de formas con comentarios sobre algunos artículos que hacen uso de las mismas, y se termina
justicando 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ígrafo
o 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.
Denido 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 trazos
procedentes del movimiento de un bolígrafo controlado por el usuario. El bolígrafo
reemplaza al teclado y a otros dispositivos de entrada. [...] El ordenador es también
capaz de reconocer texto manuscrito, por ejemplo, puede convertir garabatos en texto
de 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ón
de 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 algunas
de estas técnicas, o bien una combinación de las mismas. Para terminar, también se comentan
algunas técnicas de embellecido de las formas reconocidas ya que se consideró importante para
un entorno interactivo como el que se iba a desarrollar y que iba a servir de interfaz entre el
reconocedor y el usuario.
Reconocimiento mediante plantillas. Se dispone de una plantilla para cada clase que
representa su forma gráca típica. Esta plantilla puede haberse creado automáticamente
a partir de varias formas de ejemplo proporcionadas por el usuario de la aplicación o bien
estar predenida. Cuando el reconocedor recibe una forma desconocida, ésta se clasica en
la clase con la plantilla que más parecida es a la imagen de la gura recibida como entrada.
1
Traducción del proyectando.
3.2.
ELECCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS
49
Reconocimiento mediante grafos. Cada forma se describe mediante un grafo. Cuando el reconocedor recibe una forma desconocida, calcula su grafo asociado y lo compara
con los grafos asociados a cada una de las clases que reconoce el algoritmo clasicador.
Esto convierte el problema de reconocimiento de símbolos en un problema de detección de
isomorsmo entre grafos (graph isomorphism detection).
Reconocimiento mediante características. Sobre cada forma se calculan una serie de
características identicativas del mismo (tales como su longitud, el número de intersecciones
entre sus trazos, etc.). Cada clase en la que podría clasicarse la forma tiene unos valores
típicos para cada una de estas características, así como cierto valor de tolerancia para
las mismas y un peso para cada característica para indicar cómo de importante es ésta
en su clasicación. Cuando el reconocedor recibe una forma desconocida, ésta calcula sus
características y las compara con las que denen cada clase. Aquélla que tiene unos valores
de 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 continuació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 reconocimiento que hace uso de plantillas para cada trazo. Cada símbolo se representa como una plantilla
binaria a modo de imagen de mapa de bits representando la forma típica de la gura. Una vez
dibujada una forma nueva se compara su mapa de bits asociado con todas las plantillas representantes de las clases que se pueden reconocer, calculando cuatro medidas de similitud obtenidas
mediante cuatro clasicadores diferentes. Estas cuatro medidas se combinan en una sola para
calcular a qué clase de todas las posibles pertenece la forma recibida. A modo de ejemplo, la Figura 3.2 muestra una plantilla para una hipotética clase que representa una gura representando
un 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ánico
que 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 de
dibujado de los trazos que componen la forma a reconocer, además de ser entrenable. Funciona
creando un grafo no dirigido por cada forma en el que los nodos son las primitivas de la forma (o
líneas o arcos) y los arcos del mismo representan las relaciones geométricas que se dan entre los
pares de primitivas (número de intersecciones entre sí, la situación de las mismas y, en caso de ser
dos líneas, el ángulo que forman). Esto da lugar a un grafo con información sobre la geometría y
50
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
la topología de la gura, y debe ser comparado con el grafo que dene cada una de las posibles
clases que puede reconocer el algoritmo. Este grafo denitorio para cada clase se calcula haciendo
la media de los grafos calculados para cada uno de los trazos de ejemplo. De esta forma, una
vez segmentada una forma en sus primitivas, el problema del reconocimiento se convierte en el
problema NP-completo de detección de isomorsmos entre grafos (graph isomorphism detection) con el agravante de que se permiten distorsiones entre grafos debido a imprecisiones en
la adquisición de los trazos y en el modo de dibujado de los mismos. A modo de ejemplo, la
Figura 3.3 muestra una representación del grafo asociado a la clase cuadrado que podría ser
usada por este algoritmo.
Figura 3.3: Ejemplo de la representación de un cuadrado ideal que podría ser usado por el
algoritmo 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 del
segmento. 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 es
el de Rubine [RUB91a]. En este algoritmo un trazo se identica por una serie de características
calculadas a partir del mismo que, además, sirven para su posterior clasicación. Dado que gran
parte del resto de este capítulo habla de este reconocedor, por lo que no se comenta más de él
en esta sección.
Otro algoritmo basado en el cálculo de características es el desarrollado por Gennari et
al. [GEN05]. Éste, a diferencia del de Rubine [RUB91a], permite el reconocimiento de guras
formadas por más de un trazo y es insensible a la orientación de los mismos. Su funcionamiento
es el siguiente: una vez segmentada una forma en sus primitivas básicas (líneas o arcos) calcula
una serie de características que se dan entre ellas, tales como el número de intersecciones de
distintos tipos que se dan entre ellas, el número de trazos paralelos entre sí, el número de trazos
perpendiculares, etc.
Estas tres técnicas pueden combinarse en mayor o menor medida para formar reconocedores
que no encajan únicamente en ninguna de las categorías, como por ejemplo el desarrollado por
3.2.
51
ELECCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS
Gross [GRO94] que hace uso tanto del cálculo de características como del de plantillas. Este
reconocedor permite el reconocimiento de formas dibujadas con más de un trazo, aunque depende
del 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 dibujo
que recibe como entrada. Posteriormente, sobre este dibujo se dispone una malla de
3×3
y se
determina el orden en el que se pasó por cada cuadrante. Este orden se compara con el de las
plantillas asociada a cada clase, que a diferencia de la usada en Burak Kara [BUR05], puede ser
más de una y no almacena la forma de los dibujos, sino el orden en el que se atravesaron los
cuadrantes de la malla. Como una clase puede tener más de una plantilla, es muy posible un
dibujo se clasique como perteneciente a varias clases. Es entonces cuando la tercera fase del
reconocedor calcula ciertas características del dibujo, (tales como número de trazos, el número de
vértices o el aspecto de la caja mínima), para compararlas con las esperadas para cada clase. A
modo de ejemplo, la Figura 3.4 muestra varias de las plantillas usadas para una de las hipotéticas
clases que podría reconocer este algoritmo.
Figura 3.4: Ejemplo del uso de varias plantillas para clasicar 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ón
mejor sobre sus acciones. Aplicando este principio al reconocimiento de formas, el usuario debería
obtener información sobre lo que el sistema ha reconocido o, incluso mejor, está reconociendo
mientras el usuario está dibujando. Esto puede realizarse mediante una indicación textual, pero
lo ideal consiste en embellecer las formas reconocidas. El embellecimiento de una forma consiste
en representar ésta no como el usuario la ha dibujado, sino como éste la hubiera dibujado de
haber tenido un pulso perfecto, representando de forma perfecta una copia a escala de la forma
ideal, de acuerdo con las dimensiones del dibujado realizado por el usuario. A continuación se
comentan las diversas técnicas de embellecimiento que pueden encontrarse en la bibliografía
según el listado ofrecido por Wang [WAN05], así como algunos ejemplos de algoritmos que las
implementan:
Embellecimiento manual: es la técnica que da más control al usuario, si bien es también
la que ofrece una realimentación más tardía. Este embellecimiento se activa cuando el
usuario le da la orden expresa al sistema para que embellezca todas las guras realizadas
hasta el momento.
Embellecimiento continuo: es el modo de embellecimiento que más realimentación ofrece
al usuario puesto que el sistema está reconociendo la gura tan pronto como se dispone
de un nuevo punto de ésta, embelleciéndola constantamente y representando ésta ante el
usuario. El primero en implementar esta técnica fue Arvo [ARV00] y en el prototipo que
presentó consiguió aplicarla al reconocimiento de círculos, segmentos lineales y rectángulos
alineados con los lados de la pantalla. La Figura 3.5 muestra un ejemplo de cómo funciona
dicho algoritmo en el reconocimiento de un círculo.
52
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
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 se
parece 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 lugar
incrementalmente inmediatamente después a la detección de una esquina en el dibujo (en
el caso de polilíneas) o bien al volver al punto inicial del trazo (en el caso de círculos, por
ejemplo). Agar y Novins [AGA03] desarrollaron una variante de este método al investigar
y descubrir que es posible detectar las esquinas de un trazo jándose en las marcas de
tiempo del mismo, ya que al aproximarse a una esquina la velocidad de dibujado decrece
y al alejarse de ella vuelve a crecer. El método desarrollado por ambos toma las esquinas
como punto de partida para ir dibujando un segmento conforme el usuario va dibujando
el trazo, por lo que estrictamente hablando no se considera un ejemplo de este tipo de
embellecimiento, 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 debe
indicar al reconocedor, normalmente dejando de dibujar el trazo.
3.2.2. Justicación del algoritmo reconocedor y estrategia de embellecido
elegidas
Para la elección del algoritmo se siguió el criterio de buscar aquél más simple que diera soporte
a 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 independientemente
del escalado e insensible a la orientación del dibujado de los trazos, así como multitrazo. La
complejidad de esta tarea sugirió pensar en estrategias alternativas y se consiguió idear una
solución que, usando un reconocedor de trazos sencillo y con altas tasas de acierto, fuera capaz
de cumplir con todos los requisitos.
La estrategia que se ideó consistió en separar el reconocimiento de los trazos que componen
cada widget del reconocimiento del propio widget (se recuerda que un widget puede estar formado
por más de un trazo, tal y como se explicó en la Sección 2.2.4 en la p. 38). Esta idea de reconocer
primero los trazos y posteriormente el widget formado por éstos considerando las relaciones
geométricas que se daban entre los trazos componentes de cada uno de los widgets se tomó de
la usada por Landay [LAN01] para su aplicación SILK [SILK96]. Con esto se solucionaba el
problema de que un widget estuviera formado por varios trazos ya que un reconocedor unitrazo
basta para reconocer las formas básicas que componen todos los widgets de la aplicación a
desarrollar. El Capítulo 4 está dedicado a explicar esta estrategia.
Un reconocedor basado en plantillas hubiera solucionado tanto el problema de distintas orientaciones en el sentido de los trazos a reconocer como su escalado, por lo que se pensó en implementar el propuesto por Burak Kara [BUR05] o el de Gross [GRO94], pero éste último requería
de varias horas de uso por parte de los usuarios antes de que fuesen capaces de adaptarse a él
para lograr altas tasas de reconocimiento (algo poco recomendable). El reconocedor de Burak
Kara [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 (como
el 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 tasas
de acierto similares a las del de Burak Kara [BUR05] y, además de también ser sensible al
escalado no uniforme (y al escalado en general) era sensible a la orientación de los trazos. Para
solucionar el problema de que los algoritmos fueran sensibles a la orientación y el escalado se
optó por hacer uso de una estrategia de doble clasicación para así permitir variaciones de estos
dos tipos. Esta estrategia se comenta en la Sección 3.4.1 (p. 62) y estuvo inspirada por el artículo
de 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 Kara [BUR05]. Al nal se optó por implementar el algoritmo basado en características propuesto
por Rubine [RUB91a], que aseguraba tasas de acierto de como mínimo el 90 % para un número
muy reducido de ejemplos para cada clase, simplemente por el hecho tranquilizador de que había
sido el algoritmo elegido por los creadores de SILK [SILK96], (una aplicación muy similar a la
que se pretendía desarrollar), lo que se pensó que era una garantía importante. Este algoritmo
se 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 reconocedor, se decidió implementar una estrategia para el embellecido de guras. Se descartó la del
embellecimiento manual porque se presupuso incómoda para el usuario. La técnica de embellecimiento continuo se descartó por la excesiva complejidad de su implementación (a este respecto
puede verse el artículo de Arvo [ARV00]). Se dudó entre el embellecimiento basado en la detección
de esquinas y el realizado tras la nalización de cada trazo. Se optó por este último puesto que
el basado en la detección de esquinas se comportaba como éste en el caso de círculos, una gura
que como se vio en la Sección 2.2.5 (p. 40) la aplicación a desarrollar debía reconocer, además
de que dado que el resto de guras no eran lo bastante complejas como para ser dibujadas a
una velocidad baja o media, el uso del embellecimiento basado en la detección de esquinas no se
hubiera apreciado en la práctica.
3.3.
Descripción del algoritmo de reconocimiento de trazos elegido
3.3.1. Descripción general del algoritmo
El algoritmo elegido, ideado por Dean Rubine [RUB91a] reconoce los trazos basándose en
técnicas estadísticas. El clasicador de trazos calcula una serie de características del último trazo
dibujado y las compara con las mismas características extraídas previamente de un conjunto de
trazos de entrenamiento para cada una de las clases de trazos que reconoce. Este algoritmo reconocedor, 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 mediante
una estructura de doble clasicación (comentada en la Sección 3.4.1, p. 62) y combinarse con un
reconocedor de widgets de más alto nivel (al que se le dedica el Capítulo 4) para alcanzar dichos
requisitos de forma satisfactoria.
Por defecto, el algoritmo siempre devuelve la clase a la que es más posible que pertenezca
el trazo dibujado; aunque este comportamiento puede variarse impidiendo que devuelva algún
resultado si el trazo dibujado es rechazado por ser ambiguo o por ser probable que no pertenezca
a 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.
54
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
El clasicador (Sección 3.3.4), que dado el conjunto de características de un trazo las
compara estadísticamente con el conjunto de características que caracterizan cada una de
las clases de trazos que pueden reconocerse, y devuelve aquélla a la que más probablemente
pertenece 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 una
de las clases hace los cálculos estadísticos necesarios para extraer los pesos de las características que identican cada trazo y que serán usados posteriormente por el clasicador
para 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 clasicador si
éste devuelve una respuesta con un grado de ambidüedad en la clasicació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 la
creación de un reconocedor con altas tasas de acierto, superiores al 90 % a partir
de 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ápida
al usuario de la aplicación: se le entrega a éste un reconocedor entrenado con un número
mínimo de ejemplos que puede ir aumentando conforme aprende según las indicaciones del
usuario (este proceso se comenta al comienzo de la Sección 5.3.1 en la página 78) de forma
que se adapta rápidamente a su forma de dibujar.
Todas las partes del reconocedor tienen un bajo coste temporal. Tanto la clasicación de los trazos como su rechazo tienen lugar en un tiempo que es linealmente dependiente
del número de clases inferiores (el concepto de clase inferior se explica en la Sección 3.4.1
al nal de este capítulo), un número que no se prevé más alto de 30. El tiempo del caracterizador 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 (aunque
esto puede solventarse calculándolas de forma incremental mientras se van adquiriendo los
puntos del trazo tal y como se indica en [RUB91a, p. 333]). El entrenador es la parte más
lenta de todo el reconocedor, aún así todo el proceso consiste en el cálculo de varias fórmulas matemáticas, siendo la más compleja de ellas el cálculo de la inversa de una matriz
cuadrada 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 reconocer
los widgets que inevitablemente deben dibujarse mediante más de un trazo se ha optado por
usar 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 presente
capítulo, reconocer widgets dibujados por un número arbitrario de trazos. Esta idea se
tomó 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 bastante
dependiente respecto al escalado de los mismos. Para solucionar este problema se
ideó una estructura de varias clases jerárquicas de forma que varias clases se clasican como
una ú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 de
Gross [GRO94, p. 90] en la que una clase puede tener varias representaciones posibles que
3.3. DESCRIPCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS ELEGIDO55
clasican como una misma clase, si bien en dicho artículo las variaciones son mínimas y no
tan 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 un
trazo dado que servirán posteriormente para reconocerlo.
Rubine [RUB91a] determinó el conjunto de características comentado a continuación de forma empírica y, según él, sirven para diferenciar gran parte de clases diferentes de trazos. No
obstante, advierte que puede fallar al reconocer algunos trazos claramente distintos a simple vista debido a que éstos pueden tener características identicativas que no sean tenidas en cuenta
por el caracterizador propuesto, como por ejemplo el orden de los ángulos en el trazo. En estos
casos especiales el conjunto de características a calcular por el caracterizador puede extenderse
fácilmente para distinguir adecuadamente los trazos. No obstante, se deja constancia de que durante 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 clasicar adecuadamente nuevos trazos desconocidos, hiciera que el reconocedor fallase en el reconocimiento
de éstos.
Las características a tener en cuenta se eligieron, según [RUB91a, p. 333-334], siguiendo los
criterios siguientes:
Cada característica debe ser computable de forma incremental conforme nuevos puntos se
añaden al trazo, en tiempo constante por cada punto añadido, de forma que sea igual de
eciente calcular las características de un trazo corto que de uno largo. Esto permite que
el trazo sea reconocido antes de que sea terminado, como se explica en [RUB91b], aunque
el presente proyecto no hace uso de esta característica por una decisión de diseño (ver la
Sección 3.4, p. 61)
Dos trazos ligeramente diferentes deben tener características también ligeramente diferentes.
Cada característica debe ser lo bastante signicativa como para servir tanto para la identicación del trazo (similar a una huella digital del mismo) como para su posterior reconocimiento (ya que será el conjunto de características del trazo el que se use posteriormente
para reconocerlo)
El número de características por cada trazo debe ser el más pequeño posible que garantice
una identicació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 errores
de pulso o dibujado del trazo, a este dibujo se le realiza un preprocesado en el que se eliminan
aquellos puntos que están a menos de tres píxeles del punto anterior capturado en el proceso de
adquisición del trazo. Así pues, cada trazo consiste en un vector
g
de
P
puntos:
gp = (xp , yp , tp ) , 0 ≤ p < P
donde
xp
e
yp
son las coordenadas bidimensionales del trazo
(3.1)
p,
y
tp
el momento temporal en el
que estas coordenadas son capturadas.
Sobre este nuevo conjunto de puntos reducido se calculan las características siguientes, ilustradas en la Figura 3.6, y que forman el vector de características que identica a cada trazo:
f = [f1 , . . . , fF ],
siendo
F
el número de características (del inglés, f eatures).
56
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
Figura 3.6: Figura extraída de [RUB91c, p. 51] que sirve para ilustrar el cálculo de las caracterí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 segundo
porque el resultado suele ser más indicativo de esta forma.
x2 − x0
f1 = cos α = p
(x2 − x0 )2 + (y2 − y0 )2
f2 = sin α = p
y2 − y0
(x2 − x0 )2 + (y2 − y0 )2
(3.2)
(3.3)
Característica 3: La longitud de la diagonal de la caja de inclusión mínima del trazo.
q
f3 =
(xmáx − xmı́n )2 + (ymáx − ymı́n )2
(3.4)
Característica 4: El ángulo formado por la base de la caja de inclusión mínima del trazo
y la diagonal de ésta.
f4 = arctan
ymáx − ymı́n
xmáx − xmı́n
(3.5)
3.3. DESCRIPCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS ELEGIDO57
Característica 5: La distancia entre el primer punto y el último punto.
q
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.
(xP −1 − x0 )
f5
f6 = cos β =
(3.7)
Característica 7: El seno del ángulo formado por el primer y el último punto.
(yP −1 − y0 )
f5
f7 = sin β =
(3.8)
Característica 8: La longitud total del trazo.
Siendo
∆xp = xp+1 − xp
y
∆yp = yp+1 − yp ,
f8 =
P
−2 q
X
∆x2p + ∆yp2
(3.9)
p=0
Característica 9: La suma de los ángulos formados por todos los puntos consecutivos en
el trazo.
Siendo
∆x ∆y
−∆x
∆y
p
p−1
,
θp = arctan ∆xpp ∆xp−1
p−1 +∆yp ∆yp−1
f9 =
P
−2
X
θp
(3.10)
p=1
Característica 10: La suma de los valores absolutos de los ángulos usados en la característica 9.
f10 =
P
−2
X
|θp |
(3.11)
p=1
Característica 11: La suma de los cuadrados de los ángulos usados en la característica 9.
f11 =
P
−2
X
θp2
(3.12)
p=1
Característica 12: La máxima aceleración alcanzada durante el dibujado del trazo.
Siendo
∆tp = tp+1 − tp ,
P −2
f12 = máx
p=0
∆x2p + ∆yp2
∆t2p
(3.13)
Característica 13: El tiempo invertido en el dibujo del trazo.
f13 = tP −1 − t0
(3.14)
58
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
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 cualquier
caso para el proyecto desarrollado sí que resultaron ser sucientes 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 clase
sobre los que, una vez calculado el vector de características de cada ejemplo, se realizan los
cálculos descritos a continuación dando como resultado nal del proceso de cálculo el vector
de pesos característico para cada clase de trazos y que se usa posteriormente en el clasicador
(Sección 3.3.4, p. 59).
Hay que dejar constancia de que, según Rubine [RUB91c, p. 59], el proceso de entrenamiento
descrito 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 de
entrenamiento de forma manual para aumentar las tasas de aciertos, como se describe posteriormente 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 de
calcular la media de cada una de las características de todos los ejemplos de una misma
clase.
Sea
Eĉ
fĉei
la
i-ésima
característica del ejemplo
e-ésimo
de la clase
el número de ejemplos de entrenamiento para la clase
medio por clase,
f̄ĉ ∈ R1×F ,
c.
c,
con
0 ≤ e < Eĉ ,
siendo
El vector de características
se calcula:
Eĉ −1
1 X
¯
f ĉi =
fĉei
Eĉ
∈R
(3.15)
e=0
2.
Se calcula la matriz de covarianzas propia de cada clase.
La matriz de covarianzas para la clase
c, Σĉ ∈ RF ×F ,
se calcula adaptando la fórmula
típica del cálculo de la covarianza de una variable escalar para obtener en una matriz la
covarianza de los elementos del vector
Σĉij =
EX
ĉ −1
f̄ĉ ,
del modo siguiente:
fĉei − f¯ĉi
fĉej − f¯ĉj ∈ R
(3.16)
e=0
Esta matriz contiene la covarianza asociada a los elementos de los vectores f̄ĉ . Se hace notar
la ausencia del factor
1
Eĉ −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
PC−1
Σij =
siendo
C
c=0
C
Σĉij
Σ ∈ RF ×F :
PC−1
1
c=0 Σĉij
·
=
∈ R,
P
Eĉ − 1
−C + C−1
c=0 Eĉ
(3.17)
el número de clases que pueden reconocerse. Para claricar la ausencia del factor
1
Eĉ −1 en la Fórmula 3.16 se ha decidido exponer la Fórmula 3.17 con el paso intermedio que
3.3. DESCRIPCIÓN DEL ALGORITMO DE RECONOCIMIENTO DE TRAZOS ELEGIDO59
da lugar a la fórmula del cálculo nal de la matriz media. Se aclara que el paso intermedio
es correcto debido a que siempre habrá al menos un ejemplo para cada clase, por lo que
Eĉ ≥ 1,
4.
siempre.
Se invierte la matriz de covarianzas común calculada en el paso anterior, dando como
Σ−1 ∈ RF ×F .
resultado la matriz de covarianzas inversa
5.
Se calcula el vector de pesos de características para cada clase,
peso de la característica
j
de la clase
wĉj =
F
X
wĉ ∈ R1×F +1 .
c, wĉj ,
se calcula de la siguiente forma:
Σ−1
f¯ĉi ∈ R, 1 ≤ j ≤ F
ij
El
(3.18)
i=1
El vector de pesos de características tiene una componente adicional, almacenada en la
posición
0
de dicho vector, cuyo valor se calcula dependiendo del resto de pesos. Esta
componente adicional se calcula por defecto de la forma indicada en la Fórmula 3.19 aunque
su valor puede modicarse manualmente de acuerdo con las características concretas de las
clases que se quieran reconocer; de esta forma se evita la limitación de que todas las clases
a ser reconocidas deban ser de aparición equiprobable, según Rubine [RUB91c, p. 59].
F
wĉ 0 = −
1X
wĉi f¯ĉi ,
2
(3.19)
i=1
dando lugar así al vector de pesos de características para la clase
c, wĉ ,
que será usado por
el clasicador.
Resumiendo el proceso de entrenamiento, éste consiste en calcular la media de todos los
vectores de características de todas las clases, dando lugar a un sólo vector de características
medias para cada clase
c,
llamado
f¯ĉ .
A continuación se calcula la covarianza de dichos vectores
obteniendo así la matriz de covarianzas propia de cada clase,
Σĉ .
Se calcula la media de todas
estas matrices de covarianzas, dando lugar a una única matriz media de covarianzas,
matriz se invierte y con ella se calcula el vector de pesos para cada clase,
wĉ .
Σ.
Esta
Este vector de
pesos tiene una componente para cada característica, indicando cómo de importante es su valor
para una clase dada respecto de las otras características de la misma clase para servir así de
diferenciación con el resto de clases. Este vector tiene una componente adicional en su primera
posición,
wĉ 0 ,
calculada por defecto a partir del resto de características aunque su valor puede
modicarse manualmente para dar prioridad al reconocimiento de una clase respecto a otras.
3.3.4. Descripción del clasicador
El clasicador es la parte del reconocedor de [RUB91a] que realiza el reconocimiento propiamente dicho. Éste consiste en determinar a qué clase de trazos, de las
C
clases posibles, pertenece
un trazo dibujado. Cada clase está especicada por un conjunto de trazos de ejemplo a partir de
los cuales el entrenador (descrito en la Sección 3.3.3) determina el vector de pesos. Este vector
de pesos para cada clase
c, wĉ , se usa para clasicar un trazo de la forma indicada por la fórmula
siguiente:
vĉ = wĉ0 +
F
X
i=1
wĉi fi ∈ R, 0 ≤ c < C,
(3.20)
60
CAPÍTULO 3.
siendo
f ∈ R1×F
EL RECONOCEDOR DE TRAZOS
el vector de características del trazo a clasicar.
c
El trazo se clasica a aquella clase
cuyo
vc
es máximo. Por lo tanto, el clasicador 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 o
bien por no tener una pertenencia clara a ninguna de las clases.
3.3.5. Descripción del rechazador
El clasicador presentado siempre clasica un trazo
g como perteneciente a una de las C
clases
posibles. Por lo tanto, los trazos que no sean claramente similares a ninguna clase deberían ser
rechazados, así como aquéllos que sean ambiguos por ser muy parecidos a más de una de las
posibles clases.
Rechazo de los trazos cuya clasicación sea ambigua
Intuitivamente, un trazo es ambiguo si el valor máximo del vector de pesos para cada clase
calculado por el clasicador (Sección 3.3.4, p. 59) está muy cercano al segundo valor máximo de
dicho vector, lo que signica que el trazo, si bien se clasicó como perteneciente a una clase, la
diferencia al clasicar no es tal que pueda considerarse una clasicación no ambigua.
Para calcular el criterio de ambiguedad según Rubine [RUB91a, p. 334], sea el trazo
su correspondiente vector de características
vĵ
∀j 6= i
siendo
v ∈ R1×F
f ∈ R1×F ,
clasicado en la clase
i,
g
por lo que
con
vî >
el vector de pesos calculado por el clasicador (Sección 3.3.4). La
estimación de la probabilidad de que
g
fuese clasicado correctamente sin ambigüedades viene
dada por la fórmula:
1
P̃ î|g = PC−1
(vj −vi )
j=0 e
(3.21)
Rubine [RUB91a] recomienda rechazar aquellos trazos que cumplan la desigualdad
P̃ î|g ≤
0,95.
Rechazo de los trazos que no sean lo sucientemente parecidos a alguna clase
Una vez un trazo se ha clasicado en una clase, si éste diere mucho de los trazos tomados
como entrenamiento por la clase elegida entonces debe considerarse que el trazo realmente no
pertenece a dicha clase. Rubine [RUB91a, p. 334] usa para ello la distancia de Mahalanobis:
δ2 =
F X
F
X
Σ−1
jk
fj − f¯îj
fk − f¯îk ,
(3.22)
j=1 k=1
siendo
clases,
Σ−1 ∈ RF ×F
f ∈ R1×F el
la inversa de la matriz media de las matrices de covarianzas de todas las
vector de características del trazo considerado y
f¯ ∈ RC×F
almacenando en sus las los vectores de características medias para cada una de las
una matriz
C clases.
δ 2 > 21 F 2
Rubine [RUB91a] comenta que rechazar aquellos trazos que cumplan la desigualdad
asegura que se rechazan los trazos que obviamente no pertenecen a ninguna clase, no obstante
advierte de que puesto que también hace que se rechacen muchos trazos que sí son válidos su
uso no resulta recomendable y aconseja no implementar este método cuando la aplicación que
hace uso del reconocedor permite deshacer para permitirle al usuario borrar el último trazo
mal clasicado y redibujarlo de nuevo.
3.4. COMENTARIOS SOBRE EL DISEÑO E IMPLEMENTACIÓN DEL ALGORITMO DE RECONOCIMI
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 de
la matriz de covarianzas común (Sección 3.3.3) se usó la librería para Python SciPy
2 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 lenguaje
Python vino motivada por su sencillez y expresividad. Puesto que el reconocedor a implementar era, a juicio del autor del mismo, muy rápido, se pensó que la velocidad de este lenguaje
interpretado sería suciente para ejecutarlo en un entorno interactivo como el desarrollado para
interactuar con el reconocedor (dicho entorno se describe en el Capítulo 5). En caso de ser necesaria una ejecución muy rápida, este lenguaje permite la ejecución directa de código escrito en
otros lenguajes más ecientes, como C, por lo que siempre se podía reescribir aquellas partes del
reconocedor que fuesen intolerablemente lentas. No obstante, aunque no se realizaron pruebas
de usabilidad con los usuarios, aparentemente el reconocedor se ejecuta a una velocidad más
que suciente, tardando el entrenador unas pocas décimas de segundo en reentrenarse para un
nú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ás
características que las indicadas por Rubine [RUB91a, p. 333], no siendo necesario la introducción
de nuevas características para conseguir altas tasas de acierto de los trazos a ser reconocidos. Por
motivos 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 a
ser reconocido posteriormente) se decidió que el objeto caracterizador calculase las características
una vez terminado el trazo, y no de forma incremental conforme éste es dibujado. Esto añade
un sobrecoste a la ejecución del reconocedor puesto que las características de un trazo a ser
reconocido 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 con
la experiencia del proyectando, no es apreciable en el entorno interactivo (Capítulo 5) en el que
se usa el reconocedor.
Aunque se implementó el Rechazador (Sección 3.3.5), se decidió no usarlo porque la experiencia del proyectando probando la aplicación demostró que la mayoría de trazos eran clasicados
como no pertenecientes a ninguna clase de las posibles, algo incorrecto. Este resultado puede haber 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 recomendado 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 clasicaba en una clase, mayoritariamente correcta.
Por lo tanto se sacricaron estas dos características del reconocedor (detección de trazos no pertenecientes a ninguna clase y de clases ambiguas) en favor de un método fácil para permitirle al
usuario indicar cuál era la clase correcta en la que debía clasicarse un trazo en el caso de que
éste hubiese sido mal clasicado (ver Sección 5.3.1 en p. 78 para la explicación de esta característica), 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ón
de reconocimiento de widgets es que algunos de éstos requieren de más de un trazo para ser
dibujados, y aunque hay cierto consenso en la forma y el orden de dibujar estos trazos, no
es siempre el mismo para todas las personas (ver el estudio de dibujado de los widgets de la
Sección 2.2.4 en la p. 38). Estas dos características, reconocer formas representadas por varios
2
http://www.scipy.org
62
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
Figura 3.7: Tiempos de ejecución del entrenador del reconocedor de Rubine [RUB91a] para un
número de clases y ejemplos de cada clase variable. El ordenador en el que se tomaron los tiempos
tiene un procesador Intel Core 2 Duo a 2GHz y 1 GB de memoria DDR2 SDRAM y ejecuta el
sistema operativo Microsoft Windows XP Professional con el intérprete de Python 2.5.2 y la
versió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 reconocedor
elegido, como se comentó en la Sección 3.3.1 (p. 53). Esto último se solucionó parcialmente con
la estructura de doble clasicación comentada a continuación en la Sección 3.4.1. La solución al
problema de que un widget deba ser reconocido por medio de varios trazos tiene que ver con el
reconocedor de widgets, un reconocedor superior al de trazos, al que está dedicado el Capítulo 4.
3.4.1. Estrategia de la doble clasicación
La estrategia de la doble clasicació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 determinar
la forma de un trazo y el sentido usado en su dibujado, clasica parcialmente (un resumen de
dicho 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ás
de 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 clasicación descrita en esta sección.
3.4. COMENTARIOS SOBRE EL DISEÑO E IMPLEMENTACIÓN DEL ALGORITMO DE RECONOCIMI
Esta estrategia solventa el problema de que el reconocedor implementado sea muy dependiente
de la orientación de los trazos y bastante dependiente del escalado de los mismos, aprovecha el
hecho de que el reconocedor elegido tiene una alta tasa de aciertos incluso teniendo un número
de clases relativamente elevado (ver las tasas en [RUB91a, p. 335]).
La estrategia consiste en clasicar un trazo como una clase reconocida por el reconocedor y
que éste a su vez clasique dicha clase en otra clase superior, más general. Esta última clasicación
consiste en una simple asociación entre clases en una relación de muchas a una puesto que muchas
clases inferiores se clasican como una única clase superior, y es esta clase superior la que se
devuelve como resultado de la clasicación.
La Figura 3.8 muestra un ejemplo gráco de esta doble clasicación para una clase superior
dada. La gura muestra cuatro posibles clases inferiores asociadas a una clase superior Rectángulo. Un trazo dado se clasicará como cualquiera de las cuatro clases inferiores (si éste es
el caso) pero el reconocedor devolverá que ha sido clasicado como la clase Rectángulo, que
realmente no existe como tal ya que el reconocedor nunca clasica un trazo como perteneciente a
esa 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 trazo
de la clase rectángulo. El punto indica el comienzo de dibujado del trazo. El usuario puede dibujar
un rectángulo de cualquiera de las cuatro formas y el reconocedor lo clasicará en la clase inferior
correspondiente 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 los
trazos como de la orientación en la que se dibujen éstos, sin más que asociar a la clase superior que
se quiere que devuelva el reconocedor tantas clases inferiores como variantes se quieran permitir
para 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 para
cada clase como variantes se quieran tolerar en el dibujado para cada clase, lo que puede ser
un número relativamente elevado en el caso de guras complejas. No obstante, las ventajas de
esta técnica son claras: se trata de una estrategia sencilla que no requiere la implementación
de un reconocedor complejo que deba considerar variaciones debidas a escalado y orientación
en el modo de dibujado de los trazos, el uso de esta técnica también es independiente del tipo
de reconocedor implementado y, lo más importante, proporciona un método exible y sencillo
para añadir nuevas formas de representar un trazo permitiendo así una rápida adaptabilidad al
64
usuario.
CAPÍTULO 3.
EL RECONOCEDOR DE TRAZOS
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 reconocer
por sí sólo las representaciones de los widgets mostradas en la Sección 2.2.3 (p. 21). Esto es
debido a que dicho reconocedor de trazos sólo reconoce gestos formados por un único trazo y la
mayoría de los widgets que debe reconocer la aplicación de desarrollo de interfaces (excepto el
widget 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 trazos
dibujados y reconocidos previamente por el reconocedor de trazos, sea capaz, mediante otros
criterios 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 de
usuarios representan los widgets dibujando los trazos de las formas que lo componen en un orden
determinado, 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 de
inclusió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 de
trazos acaba de dibujar en la aplicación, ésta embellece los trazos, borrando aquéllos dibujados a
mano alzada y sustituyéndolos por las guras que representan las clases dibujadas. Para conseguir
mayor similitud se hace que estas guras tengan la misma caja de inclusión mínima que el trazo
desde 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 superior
o 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 reconocedor
de trazos le indica que un trazo determinado pertenece a una clase superior dada hasta que lo
transforma en su elemento correspondiente: el reconocedor de widgets recibe la caja de inclusión
mínima del trazo y la clase superior en la que éste se clasica y crea el elemento correspondiente
con la misma caja mínima.
Los widgets son elementos formados a partir de otros dos elementos, sean éstos widgets o clases
superiores. La denición de la creación de los widgets se especica mediante una serie de reglas
65
66
CAPÍTULO 4.
EL RECONOCEDOR DE WIDGETS
Figura 4.1: Una vez un trazo ha sido clasicado por el reconocedor de trazos, la clase a la que
pertenece éste y su caja mínima se introducen en el reconocedor de widgets, que crea el elemento
correspondiente a la clase recibida con la caja mínima del trazo dibujado (en el caso de un círculo
se opta por dibujarlo con un diámetro igual al del lado mayor de la caja mínima, como se muestra
en la gura). Una vez creado el elemento círculo, éste volvería a introducirse en el reconocedor
de widgets para determinar si con información de su contexto éste se une a otro elemento para
formar otro nuevo, tal y como se explica posteriormente en la Sección 4.2.3 (p. 68).
sencillas, predenidas y jas. Cada vez que el usuario dibuja un nuevo trazo, éste es clasicado en
una clase superior y convertido a su elemento correspondiente. Este último elemento reconocido
es el que se usa para compararlo con todos los demás elementos previamente dibujados para ver
si 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 que
ocupa 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 un
nuevo elemento resultado de la regla.
A continuación se explican los criterios de posición que se usan en la denición de las reglas,
posteriormente la sintaxis de las mismas y por último se explica en detalle el algoritmo de
reconocimiento de widgets.
4.2.1. Relaciones posibles entre dos elementos
El reconocedor de widgets reconoce los widgets a partir de dos elementos, sean clases superiores o widgets, mediante relaciones de inclusión o exclusión y relaciones de situación entre ellos (a la
izquierda, a la derecha, etc.). A continuación se describen estas relaciones de inclusión/exclusión
y de situación.
Las relaciones de inclusión/exclusión son las siguientes, y un elemento respecto a otro sólo
puede cumplir una de las dos:
Un elemento
mínima del
A está contenido dentro de otro elemento B si la caja de inclusión
elemento A está contenida en la del elemento B , permitiendo la superposición
de los bordes de las cajas.
Un elemento
a
B,
A no está contenido por otro elemento B
si el elemento
A no contiene
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 cumplir
una de ellas:
Un elemento
A está a la izquierda de otro elemento B si todos los vértices de la caja
A están a la izquierda de, o superpuestos con, todos los vértices
de inclusión mínima de
4.2.
FUNCIONAMIENTO DEL RECONOCEDOR DE WIDGETS
de la caja de inclusión mínima de
caja de inclusión mínima de
mínima de
A
B,
67
y si la línea horizontal que pasa por el centro de la
no está ni por encima ni por debajo de la caja de inclusión
B.
Un elemento
A está a la derecha de otro elemento B si todos los vértices de la caja
A están a la derecha de, o superpuestos con, todos los vértices de la
caja de inclusión mínima de B , y si la línea horizontal que pasa por el centro de la caja de
inclusión mínima de A no está ni por encima ni por debajo de la caja de inclusión mínima
de B .
de inclusión mínima de
Un elemento
A está arriba de otro elemento B si todos los vértices de la caja de
A están por encima de, o superpuestos con, todos los vértices de la
caja de inclusión mínima de B , y si la línea vertical que pasa por el centro de la caja de
inclusión mínima de A no está ni a la izquierda ni a la derecha de la caja de inclusión
mínima de B .
inclusión mínima de
Un elemento
A está debajo de otro elemento B si todos los vértices de la caja de
inclusión mínima de A están por debajo de, o superpuestos con, todos los vértices de la
caja de inclusión mínima de B , y si la línea vertical que pasa por el centro de la caja de
inclusión mínima de A no está ni a la izquierda ni a la derecha de la caja de inclusión
mínima de B .
El elemento
A está centrado en el elemento B si el elemento A está contenido
y la caja de inclusión mínima de A corta a la línea perpendicular al lado más largo
caja de inclusión mínima de B y que pasa por el centro de ésta.
en
B
de la
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 del
centro 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 del
centro 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 del
centro 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á contenido
en éste y además toda la caja de inclusión mínima de A está por debajo del centro de la
caja de inclusión mínima de B .
4.2.2. Reglas de deniciones de los widgets
Las reglas para reconocer widgets se encuentran en un chero de texto con una sintaxis
especial. Cada línea de este chero termina en salto de línea y se ignoran aquéllas que comienzan
por el carácter punto y coma ; o están en blanco. Una regla debe ocupar una única línea y
seguir 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 de
barra vertical |. Estas cinco partes se describen a continuación:
68
CAPÍTULO 4.
EL RECONOCEDOR DE WIDGETS
Elemento Existente: el nombre de una clase superior o widget que se hubiera dibujado y
reconocido como tal previamente. En caso de ser el nombre de una clase éste debe coincidir
con alguno de los nombres de las clases superiores del reconocedor de trazos que usa el
reconcedor de widgets. El nombre del widget debe coincidir con el nombre de algunos de
los widgets a ser reconocidos.
Elemento Nuevo: el nombre de la clase o widget que se acaba de reconocer justo antes
de aplicar la regla. Al igual que en el caso del componente anterior de la regla, en caso
de ser el nombre de una clase éste debe coincidir con alguno de los nombres de las clases
superiores del reconocedor de trazos. El nombre del widget debe coincidir con el nombre
de algunos de los widgets a ser reconocidos.
Inclusión / exclusión: indica la relación de inclusión/exclusión entre ambos elementos, el
Elemento Existente respecto al Elemento Nuevo. Toma únicamente un valor de entre los
valores Dentro o Fuera para indicar respectivamente los criterios de inclusión o exclusión
descritos en la Sección 4.2.1.
Elemento Existente
Elemento Nuevo. Con únicamente un valor de entre la lista de Arriba, Abajo,
Situación: indica la relación de situación entre ambos elementos, el
respecto al
Derecha, Izquierda, Centro, * que junto con la relación de inclusión / exclusión de la
parte anterior de la regla indica alguno de los criterios de relaciones de situación posibles
entre dos elementos descritos en la Sección 4.2.1. El valor asterisco * agrupa cualquiera
de los otros cinco posibles valores de posición.
Widget: el nombre del nuevo widget que se forma a partir del elemento ya existente (de
la primera parte de la regla) y del nuevo elemento recién reconocido (de la segunda parte
de la regla), cumpliendo con las relaciones de situación e inclusión/exclusión especicadas
para la regla.
4.2.3. Funcionamiento del algoritmo reconocedor de widgets
El algoritmo de reconocimiento de widgets comienza creando el elemento correspondiente
a la clase superior a la que pertenece el último trazo reconocido por el reconocedor de Rubine [RUB91a]. Una vez creado el mismo, se introduce en el conjunto de elementos que se encuentran representados en la pantalla de la aplicación y se comprueba a continuación si el nuevo
elemento hace que se cumpla alguna regla de las especicadas en el chero de reglas para, si es
así, crear el nuevo elemento, de tipo widget, sustituyendo a ambos elementos (el dibujado y el
que le ha servido de pareja en la regla)
Se transcribe a continuación el pseudocódigo. Se comienza listando el seudocódigo que se
encarga de, dada la clase superior a la que pertenece el último trazo dibujado, crear el elemento correspondiente, insertarlo en el conjunto de elementos y llamar a la función encargada de
comprobar 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
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.
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 al
usuario 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 una
caja de inclusión mínima que depende de la del trazo del que proviene y es calculada por la
función
especificarCajaMinima(). ConjuntoElementos contiene todos
Pizarra y son visibles por el usuario.
aquellos elementos que
se encuentran representados en la
A continuación se transcribe el código encargado de determinar si el último elemento introducido en el conjunto de elementos hace que se cumpla alguna regla y si es así de crear el nuevo
widget resultante de la aplicación de ésta.
funcion ConjuntoElementos::reconocerWidgets() es
maximaDistancia = INFINITO
reglaCumplida = Falso
ultimoElemento = listaElementos = getNumElementos()
listaCercania = listaElementos.ordenarDeCercanoALejano(ultimoElemento)
para cada elemento en listaCercania hacer
inclusion = determinarInclusion(ultimoElemento, elemento)
situacion = determinarSituacion(ultimoElemento, elemento, inclusion)
si (inclusion == "Dentro") y (posicion != "Error") entonces
nombreNuevoElemento = Reglas.buscarRegla(elemento, ultimoElemento, inclusion, situacion)
si nombreNuevoElemento != None entonces
reglaCumplida = Cierto
elementoRegla = elemento
break
finsi
si no si (inclusión == "Fuera") y (posicion != "Error") entonces
umbralDistancia = 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 = distancia
reglaCumplida = Cierto
elementoRegla = elemento
finsi
finsi
finsi
finpara
70
EL RECONOCEDOR DE WIDGETS
CAPÍTULO 4.
si reglaCumplida entonces
nuevoElemento = 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 éstos
de menor a mayor distancia respecto del último elemento reconocido, si alguno cumple una regla
con éste. Para ello lo primero que hace es crear la lista
listaCercania,
que es la lista de todos
los elementos del conjunto exceptuando al último introducido, ordenada según un criterio de
distancia de más cercano a más lejano tomando como referencia el último elemento introducido
en la lista
listaElementos. A continuación recorre esta lista y, si el nuevo elemento se encuentra
dentro 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 encuentra
dentro de ningún otro, se compara con todos los demás siguiendo un criterio de cercanía, y el
elemento más cercano que haga que se cumpla alguna regla será el que se use para crear un nuevo
elemento. Para crear el nuevo widget, el objeto
Elemento
lo crea según su nombre. Se inserta el
nuevo elemento y se borran aquéllos dos que se han usado para crear el nuevo y la función se
llama 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.2
y que el código del reconocedor de widgets hubiera sido independiente de dichas reglas. A la
hora de desarrollar el proyecto se decidió desarrollar un código que fuera lo más independiente
posible de estas reglas considerando las limitaciones de tiempo de la asignatura de Proyectos
Informáticos.
El código desarrollado ha resultado ser sólo parcialmente independiente de las reglas. En
concreto, 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 que
haga uso de un widget o elemento que no tenga su clase asociada en el código llamándose igual
a é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 iconos
mientras 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 los
algoritmos 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.
4.4. REGLAS DE RECONOCIMIENTO DE WIDGETS USADAS POR LA APLICACIÓN DEL PROYECT
PizarraAplicacion.py:
Implementa la zona de la aplicación en la que el usuario puede
dibujar sus trazos. En el evento de levantar el botón izquierdo del ratón asociado a la zona
de dibujo es donde se reconoce el trazo y se clasica en una clase superior, y desde donde
se llama a la función
Elementos.py:
reconocerWidgets()
descrita en la Sección 4.2.3.
Implementa la clase del objeto
Elementos
usado en los algoritmos de la
Sección 4.2.3.
4.4.
Reglas de reconocimiento de
widgets
usadas por la aplicación
del proyecto
A continuación se listan las reglas usadas por la aplicación del proyecto para reconocer los
widgets y se termina el capítulo comentando algunas de ellas, a modo de ejemplo.
; Caja Multilínea
Rectangulo Horizontal | Barra De Desplazamiento Vertical | Dentro | Derecha | Caja Multilinea
; Barra de iconos.
Rectangulo Horizontal | Cuadrado | Dentro | * | Barra De Iconos
Barra De Iconos | Cuadrado | Dentro | * | Barra De Iconos
; Botón de selección múltiple.
Cuadrado | Texto | Fuera | Derecha | Boton De Seleccion Multiple
Boton De Seleccion Multiple | Boton De Seleccion Multiple | Fuera | Abajo | Boton De Seleccion Multiple
Boton De Seleccion Multiple | Boton De Seleccion Multiple | Fuera | Arriba | Boton De Seleccion Multiple
; Botón de radio.
Circulo | Texto | Fuera | Derecha | Boton De Radio
Boton De Radio | Boton De Radio | Fuera | Abajo | Boton De Radio
Boton De Radio | Boton De Radio | Fuera | Arriba | Boton De Radio
; Botón
Rectangulo Horizontal | Texto | Dentro | Centro | Boton
; Cuadro combinado
Rectangulo Horizontal | Cunya Or | Dentro | Derecha | Cuadro Combinado
; Barra de
Rectangulo
Rectangulo
Rectangulo
desplazamiento horizontal
Horizontal| Rectangulo Horizontal | Dentro | Centro | Barra De Desplazamiento Horizontal
Horizontal| Cunya Menor Que | Dentro | Izquierda| Barra De Desplazamiento Horizontal
Horizontal| Cunya Mayor Que | Dentro | Derecha| Barra De Desplazamiento Horizontal
; Barra de
Rectangulo
Rectangulo
Rectangulo
desplazamiento vertical
Vertical | Rectangulo Vertical | Dentro | Centro | Barra De Desplazamiento Vertical
Vertical | Cunya And | Dentro | Arriba | Barra De Desplazamiento Vertical
Vertical | Cunya Or | Dentro | Abajo | Barra De Desplazamiento Vertical
; Caja de entrada de texto. Primero el rectángulo y luego el texto para no confundirlo con texto
; al lado de un botón.
Rectangulo Horizontal | Texto | Fuera | Izquierda | Caja De Entrada De Texto
; Barra de menú.
Rectangulo Horizontal | Texto | Dentro | * | Barra De Menu
Barra De Menu | Texto | Dentro | * | Barra De Menu
A continuación se comenta el dibujado paso a paso del widget Caja Multilínea y cómo
dicho widget se va reconociendo a partir de los trazos que se van clasicando en clases superiores
y posteriormente ejecutándose las reglas de reconocimiento para ir creando los elementos que
terminan en el widget denitivo. Los pasos que se comentarán se encuentran representados en la
Figura 4.2.
72
CAPÍTULO 4.
EL RECONOCEDOR DE WIDGETS
Figura 4.2: Ejemplo del dibujado del widget Caja Multilínea
Se comienza dibujando un trazo (Figura 4.2(a)) que el reconocedor clasica como de la clase
superior Rectangulo Horizontal. Ésto es recibido por el reconocedor de widgets y lo embellece, 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ínima
que el trazo del que se reconoció. Este elemento se introduce en el conjunto de elementos. Puesto que únicamente se dispone de un elemento introducido, el algoritmo de búsqueda de reglas
implementado por la función
reconocerWidgets()
del pseudocódigo de la Sección 4.2.3 no se
ejecuta.
Sobre este elemento se dibuja un nuevo trazo (Figura 4.2(c)) que es clasicado por el reconocedor de trazos como perteneciente a la clase superior Rectángulo Vertical. El reconocedor
de widgets crea el elemento correspondiente,
Rectangulo Vertical,
y dibuja su representación
consistente en un rectángulo vertical de color rosado (Figura 4.2(d)). El elemento se inserta en
el conjunto de elementos. Se ejecuta el algoritmo de búsqueda de reglas pero no se encuentra
ninguna que consista en un
Horizontal.
Rectangulo Vertical
dentro y a la derecha de un
Rectángulo
Se dibuja un nuevo trazo dentro de este último rectángulo (Figura 4.2(e)) que es clasicado por el reconocedor de trazos como perteneciente a la clase superior Cunya Or. Lo que
ocurre 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 el
elemento correspondiente,
Cunya Or,
y dibuja su representación consistente en un rectángulo
isósceles de color amarillo. Se introduce dicho elemento en el conjunto de elementos y se ordenan
por 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 abajo
de 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() comentada
anteriormente, se para de buscar nuevas correspondencias de reglas. Se crea entonces el nuevo
elemento,
Barra De Desplazamiento Vertical,
y se inserta en el conjunto de elementos. Se
borran 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
reconocerWidgets() por si ésta hiciera que
glas, se ejecuta de nuevo la función
una de las rese cumplieran
nuevas reglas que dieran lugar a nuevos widgets. En esta nueva ejecución de la función se mira si el nuevo elemento creado, la
Barra De Desplazamiento Vertical, cumple alguna regla
Rectangulo Horizontal).
con alguno de los elementos preexistentes (en este caso únicamente el
4.4. REGLAS DE RECONOCIMIENTO DE WIDGETS USADAS POR LA APLICACIÓN DEL PROYECT
Barra de Desplazamiento Vertical está en el interior derecho de un
Rectangulo Horizontal esto da lugar al elemento Caja Multilinea, con el widget de su mismo
Se descubre que si una
nombre. Se introduce el elemento nuevo y se eliminan los dos anteriores que se han tomado como
origen para la regla. Sólo se tiene ahora un elemento y no cumple ninguna regla, por lo que el
aspecto nal es el de la Figura 4.2(f ), que es lo que acaba viendo el usuario al nal de todo este
proceso.
74
CAPÍTULO 4.
EL RECONOCEDOR DE WIDGETS
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 entrenador
del 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, llamada
HandStroke. Las dos aplicaciones anteriores son independientes entre sí.
La aplicación Entrenador, que implementa la interfaz del entrenador de trazos, permite que el
usuario pueda denir las clases en las que clasicar los trazos que se dibujen, así como los trazos
de 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 Rubine [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ón
anterior. El reconocedor de widgets (descrito en el Capítulo 4) se encuentra implementado directamente 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 trazos
de Rubine [RUB91a], llamada Entrenador, tiene el aspecto de la Figura 5.1. A continuación se
comenta brevemente la funcionalidad de cada elemento de esta interfaz y posteriormente se
describen 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 usuario
denir las clases que vaya a usar el reconocedor de Rubine [RUB91a] para clasicar sobre ellas
los trazos, en una estructura de clases de tipos inferior y superior de acuerdo con lo descrito en
la Sección 3.4.1.
Para permitir un entrenamiento del reconocedor, cada clase debe tener al menos un trazo
de ejemplo que sirva para realizar un entrenamiento. Además, la aplicación Entrenador permite
realizar un entrenamiento con los datos de los que se dispone, así como borrar clases introducidas
previamente y visualizar los trazos de cada una de ellas. Seguidamente se comenta brevemente
có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.
Denir una nueva clase para el reconocedor
Para denir una nueva clase debe hacerse clic sobre el botón Añadir clase de la ventana de la
Figura 5.1, lo que lleva a la ventana mostrada en la Figura 5.2 desde donde se pueden introducir
los nombres de las clases superior e inferior del reconocedor (ver la Sección 3.4.1, p. 62, en la
que se explica el fundamento de esta doble clasicación). Para asociar una clase inferior a una
superior ya existente debe teclearse en este diálogo el nombre de la clase superior tal cual se
denió ésta la primera vez, puesto que la asociación de diversas clases inferiores a una misma
clase 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 la
ventana de la interfaz de la Figura 5.1, lo que lleva al diálogo de la Figura 5.3. Por cada clase
superior puede elegirse borrar una clase inferior en concreto o bien todas sus clases inferiores
seleccionando 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 denida previamente desde la aplicación
Entrenador.
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 ya
existente 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 para
introducir el trazo en la lista de trazos de la clase. Si se cometen errores al dibujar un trazo éste
puede 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ás
antiguo según su fecha de dibujado, en el listado de trazos del centro de la ventana de la Figura 5.1
sin 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 espacio
dedicado a cada trazo. Se pueden visualizar a su tamaño original sin más que hacer clic sobre
una de estas muestras, apareciendo así una ventana como la de la Figura 5.4 en la que el trazo
se muestra a su tamaño real. Desde esta ventana, además, puede animarse el dibujado del trazo
por 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 todas
las 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 el
reconocedor de Rubine [RUB91a], descrito en el Capítulo 3. Este reconocedor es el que usa la
aplicació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értices
de todos los trazos de los que dispone de ejemplo. Esto no es necesario para realizar un reconocimiento ya que únicamente son necesarias las características calculadas por el caracterizador (un
componente del reconocedor de trazos descrito en Sección 3.3.2, p. 55), sin embargo la aplicación Entrenador los necesita para poder mostrar los trazos visualmente. De hecho, esta aplicación
simplemente consiste en una interfaz gráca para interactuar con dicho objeto reconocedor y
permitir insertar o borrar nuevas clases y trazos asociados a ellas. Para una descripción de la
organización del código del reconocedor se remite a la Sección 3.4 (p. 61), en la que se describe
éste.
78
CAPÍTULO 5.
LAS APLICACIONES DESARROLLADAS
Figura 5.4: El diálogo desde el que puede visualizarse cualquiera de los trazos asociados a cualquier 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 de
diseño rápido de interfaces. La interfaz de la aplicación, mostrada en la Figura 5.5, consta de
tres zonas diferenciadas, comentadas a continuación.
La primera zona consiste en la barra de menú. Desde ésta se puede guardar un diseño de
interfaz, cargar un diseño guardado en disco, borrar la zona de dibujo para comenzar a dibujar
una 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 puede
dibujar los trazos que, al ser reconocidos por el reconocedor de trazos y posteriormente de widgets
se transforman en los elementos que son representados visualmente, de acuerdo con lo expuesto
en 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 informativo
indicando cuál fue la clase en la que se clasicó el último trazo reconocido por el reconocedor
de 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 forma
adecuada por el reconocedor, el usuario puede pulsar el botón Reconocer manualmente para
que 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 conjunto
de trazos de ejemplo de dicha clase y el reconocedor de trazos se reentrenará automáticamente
teniendo 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ás
que hacer clic sobre el elemento en cuestión, lo que hace aparecer el diálogo para modicar las
etiquetas (Figura 5.7).
Operaciones de deshacer y borrar
Además de la posibilidad de guardar y cargar una interfaz realizada con anterioridad y de
borrar completamente todo lo dibujado en la pizarra, la aplicación permite realizar las acciones
de deshacer el último trazo reconocido y de borrar un elemento seleccionado de los dibujados
en la interfaz. Estas dos funcionalidades se realizan por medio de dos gestos realizados por el ratón
y 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ándolo
desde un píxel de dentro del elemento a borrar. Al reconocerse el gesto, el elemento se borra
completamente.
80
CAPÍTULO 5.
LAS APLICACIONES DESARROLLADAS
Figura 5.6: Diálogo de la aplicación HandStroke desde el que el usuario puede reconocer manualmente el último trazo dibujado en el caso de que éste no haya sido reconocido adecuadamente.
Figura 5.7: Diálogo para modicar 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 que
contenga el elemento.
Figura 5.8: Ejemplo de trazo reconocido por la aplicación HandStroke para indicar que debe
borrarse el elemento que contenga el píxel sobre el que se inicie el gesto. El punto indica el
comienzo 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 signica que si el último trazo
5.3.
81
DESCRIPCIÓN DE LA APLICACIÓN DE DISEÑO DE INTERFACES
dio lugar a una creación de un elemento nuevo (por ejemplo, un cuadrado) o transformación de
un elemento ya existente (por ejemplo, un texto al lado de un cuadrado daría lugar a un botón
de selección múltiple), estos elementos desaparecen o bien vuelven a su estado anterior (por
ejemplo, el botón de selección múltiple pasa a ser un cuadrado porque se deshace el último trazo
reconocido, 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 debe
deshacerse 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 resultado de una sucesión de trazos consecutiva destinados a crear un botón de selección múltiple
con dos elementos (Uno y Dos). Las distintas guras muestran los distintos estados debidos
a la aplicación sucesiva de la acción deshacer: en (b) se vuelve al valor original de las etiquetas
del widget, en (c) se deshace el trazo clasicado como de la clase
Texto
para así quedarse con
un cuadrado únicamente, por lo que de acuerdo con las reglas del reconocedor sólo se tiene un
botó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ódigo
de la interfaz diseñada. El código se escribe en C++ y usa la librería para interfaces grácas
FLTK [SPI08].
Se generan tres cheros de código, uno con las denición de la clase y sus métodos, otro
con la especicación de los mismos y un tercero con la función
main()
que sirve para poder
ejecutar un programa de prueba en el que se vea funcionar la aplicación. Además, para facilitar
1 en
la tarea de compilación se genera también un archivo de proyecto propio del IDE Dev-C++
1
http://www.bloodshed.net/devcpp.html
82
CAPÍTULO 5.
LAS APLICACIONES DESARROLLADAS
2
su versión 5 .
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 HandStroke y el resultado (parte (b)) de compilar el código generado por dicha aplicación para el mismo
ejemplo.
5.3.2. Detalles de implementación
La aplicación HandStroke hace uso tanto del reconocedor de Rubine [RUB91a] descrito en el
Capí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 encuentra implementado directamente sobre la aplicación HandStroke, por lo tanto los comentarios
del 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 elemento
determinado reconocer un widget es el que se describe en la Sección 4.2.3 (página 68).
En 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.
2
Capítulo 6
Conclusiones y valoración crítica del
proyecto
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 de
usuario. Esto se ha conseguido mediante la creación de un reconocedor de elementos de interfaces
grácas, llamados widgets, desarrollando un reconocedor para los mismos que es simple a la vez
que eciente y con altas tasas de acierto.
Desde un punto de vista personal, el proyecto ha supuesto la adquisición de nuevos conocimientos académicos de la disciplina de la interacción persona-computador y de la captura de
requisitos, 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 medio
de la elección de un algoritmo de reconocimiento de trazos complejo como se pensó en un primer
momento, sino que, al realizar el estudio de las necesidades de los posibles futuros usuarios de una
aplicación como la desarrollada (Capítulo 2) y una investigación bibliográca sobre los algoritmos
de reconocimiento de trazos (Sección 3.2, p. 48), se descubrió que la tarea de reconocimiento
de 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 reconocer
las 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 trazos
clasicados por el reconocedor de trazos, sí que los reconoce. Si bien este reconocedor de widgets
no reconoce todos los widgets que, según la Sección 2.2.1, debería reconocer para cumplir con los
requisitos, esta limitación tiene que ver con las restricciones temporales del proyecto, y no con
las restricciones propias de dicho reconocedor, ya que sería posible extenderlo fácilmente para
reconocer 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 parte
de los requisitos expuestos en la Sección 2.3.3 (p. 45) que exigieron los usuarios participantes en
el análisis de requisitos. Deja sin soporte los requisitos R3 (permitir crear un storyboard para
indicar 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 el
reconocimiento de trazos y su desarrollo no sería más que cuestión de disponer de más tiempo
de desarrollo. El requisito R13 que exige que la aplicación se ejecute tanto sobre Windows XP
como sobre GNU/Linux se considera parcialmente conseguido ya que si bien el lenguaje usado
en el desarrollo del proyecto es multiplataforma, éste únicamente se desarrolló y probó sobre un
sistema 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ón
desarrollada con usuarios, la propia experiencia del proyectando, así como el análisis de requisitos
realizado (Capítulo 2) hacen pensar en que el proyecto desarrollado permite el prototipado rápido
de interfaces de usuario generando parte del código asociado a éstas, por lo que se considera que
los 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 esta
secció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 especicar de forma
gráca algunos de los eventos sencillos asociados a algunos widgets. La implementación de un
storyboard para las transiciones entre ventanas o cambios de comportamiento asociado a cada
una de ellas sería más complejo, aunque su consecución únicamente sería cuestión de más tiempo
de programación y no implicaría esfuerzo intelectual notable. Más a largo plazo, y pensando en el
desarrollo de una aplicación comercial, sería urgente implementar cuantas más posibilidades de
interacción mejor, tales como la posibilidad de mover los elementos dibujados, su redimensión, su
copiado, cortado y pegado, etc., todo ello haciendo uso también de una interacción basada en el
reconocimiento de los gestos por parte del usuario. Sería interesante, además, permitir diferentes
visiones, con distinta granularidad, de la interfaz diseñada. Esto facilitiaría la tarea de diseñar de
forma fácil interfaces complejas con elementos anidados (tales como marcos con elementos en su
interior). Otra idea interesante a largo plazo sería desarrollar una aplicación como la descrita en
este proyecto que formase parte de una herramienta de desarrollo visual, a modo de módulo. De
esta forma se podría aprovechar la rapidez de prototipado y la facilidad de uso de una aplicación
como la desarrollada en este proyecto y la capacidad de manipulación a bajo nivel (escritura de
código) que permiten estos entornos visuales.
Apéndice A
Cuestionario de análisis de requisitos
iniciales
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 la
secció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 sección 2.2.2 y siguientes.
87
Figura A.2: Página 2 de 6 del cuestionario de análisis de requisitos iniciales descrito en la sección 2.2.2 y siguientes.
88
APÉNDICE A.
CUESTIONARIO DE ANÁLISIS DE REQUISITOS INICIALES
Figura A.3: Página 3 de 6 del cuestionario de análisis de requisitos iniciales descrito en la sección 2.2.2 y siguientes.
89
Figura A.4: Página 4 de 6 del cuestionario de análisis de requisitos iniciales descrito en la sección 2.2.2 y siguientes.
90
APÉNDICE A.
CUESTIONARIO DE ANÁLISIS DE REQUISITOS INICIALES
Figura A.5: Página 5 de 6 del cuestionario de análisis de requisitos iniciales descrito en la sección 2.2.2 y siguientes.
91
Figura A.6: Página 6 de 6 del cuestionario de análisis de requisitos iniciales descrito en la sección 2.2.2 y siguientes.
92
APÉNDICE A.
CUESTIONARIO DE ANÁLISIS DE REQUISITOS INICIALES
Apéndice B
Entrevistas realizadas a diseñadores
para la adquisición de requisitos para la
aplicación
Durante la fase de captura de requisitos para la aplicación del proyecto (ver el capítulo 2) se
realizaron ocho entrevistas a estudiantes que habían diseñado y desarrollado, en algún momento
de su vida reciente, alguna interfaz gráca en la que habían prestado atención al proceso de
diseño de la misma. A estas personas se las llamará de ahora en adelante diseñadores, y no
desarrolladores.
Las entrevistas se realizaron individualmente y cada una de ellas no duró más de veinte
minutos. Las preguntas realizadas se enumeran a continuación. Posteriormente se indican las
respuestas 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 dicultad encontrada durante el proceso de desarrollo de la interfaz
por 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 desarrollo 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 practicada
en 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 REQUISITO
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 practicada
en 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 interfaces 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 la
asignatura Entornos de usuario.
Usuario/a 5
La última interfaz la realizó hace unos tres meses para su proyecto nal de carrera. Antes de
eso 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 la
asignatura 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 la
asignatura 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ón
a los detalles que el mínimo necesario para que se distinguiera claramente lo que representaba
cada elemento del dibujo.
Si necesitaba claricar algún detalle de una interfaz que no podía quedar claro sólo con el
dibujo, por ejemplo el comportamiento de un elemento de la misma al interactuar sobre él, lo
que hacía era escribir un texto explicativo a mano, cerca del elemento en cuestión y unido a éste
por una echa. Si este comportamiento consistía en abrir otra ventana distinta lo que hacía era
numerar las ventanas de cada aplicación para poder distinguir unas de otras y escribir un texto
indicando que se abría la ventana numerada.
Los combo box normalmente los dibujaba abiertos para que quedase claro su comportamiento. Esto no le provocaba problemas de distribución de espacio en el dibujo porque los elementos
que dibujaba estaban separados entre sí. Si los dibujaba plegados, en su opinión, quedaba menos
claro el comportamiento de dicho elemento.
Los dibujos que realizaba no eran denitivos, sino que se iban modicando conforme añadía
mejoras, 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 incluido
con las distintas versiones del sistema operativo Microsoft Windows. Las formas utilizadas más
frecuentemente eran los rectángulos, con la variante de rectángulo con borde redondeado para
representar los botones. Este método le resultaba rápido, sobre todo una vez tenía dibujados
algunos widgets, ya que el resto se creaban copiando y pegando, y modicando ligeramente la
apariencia.
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 posible
mediante dibujos en Microsoft Paint.
La versión anotada, que tomaba como base la versión limpia y que explicitaba, mediante
notas, 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 interfaz
con Visual Basic o con Java SWING.
Cuando programa en Visual Basic (usa las versiones 6.0, o .NET más frecuentemente) lo
hace por razones de trabajo. Su jefe le manda realizar un formulario con una determinada
función. Su experiencia hasta el momento de realizar la entrevista es que siempre antes
algú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 se
sirve de la herramienta de diseño de arrastrar y soltar que trae por defecto el entorno
de desarrollo de Visual Basic. Así que simplemente arrastra los elementos nuevos y ajusta
las propiedades de los mismos mediante un formulario del entorno (por lo que no escribe
código de la aplicación de forma manual), y/o borra los elementos de la interfaz que toma
como base y que no le sirven en la interfaz nueva.
Como siempre se basa en formularios desarrollados anteriormente, nunca hace ningún estudio de usabilidad de la aplicación a desarrollar, ya que supone que los formularios que
toma como base han sido considerados usables por el equipo de desarrollo.
Cuando programa en Java SWING, dado que no conoce ningún entorno de desarrollo
visual para usar esta librería, sí que necesita diseñarse la interfaz a implementar. Para ello
la dibuja en papel y dispone los elementos teniendo en mente que luego va a tener que
situarlos usando los Panels de SWING.
Usuario/a 4
El proyecto anteriormente citado para la asignatura Entornos de Usuario se realizaba en
grupo, 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 interfaces
diseñadas. Esta interfaz nueva se dibujaba manualmente.
En los dibujos, para representar que al interactuar con un elemento de la interfaz se producía
un 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 elementos
de la misma no fueron considerados por no ocurrírseles.
96APÉNDICE B. ENTREVISTAS REALIZADAS A DISEÑADORES PARA LA ADQUISICIÓN DE REQUISITO
Con la nueva interfaz se realizaban entrevistas con usuarios para evaluar su usabilidad. A los
usuarios se les planteaban preguntas que tenían que responder. Las repuestas dadas servían para
determinar qué aspectos de la interfaz desarrollada eran mejorables, aunque ésta durante todo
el proceso de las entrevistas permanecía inmutable.
Una vez terminadas las entrevistas se actualizaba la interfaz con las mejoras descubiertas con
los usuarios. Esta nueva interfaz se consideraba como denitiva, y era la que se usaba como guía
para la implementación.
Usuario/a 5
El entrevistado no hizo prototipos previos, de ningún tipo, para ninguna de las interfaces
realizadas.
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 aplicació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 que
iban 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 dibujada
en una hoja distinta. Este diseño se le enseñaba a los usuarios y se les pedía la opinión sobre
los mismos. Si varios usuarios le pedían modicar algún detalle de la interfaz lo modicaban,
siguiendo más bien el criterio de los desarrolladores de la interfaz que el del propio usuario. Con
este proceso se llegaba al diseño denitivo que posteriormente se intentaba implementar.
Usuario/a 7
El proyecto anteriormente citado se realizó en pareja, y la forma de trabajar acordada entre
los 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 interfaces
diseñadas. Esta interfaz nueva se dibujaba manualmente.
En los dibujos, para representar que al interactuar con un elemento de la interfaz se producía
un 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 elementos
de la misma, por ejemplo el cambio en un widget al interactuar con otro, se representaban con
una echa que salía del widget de la ventana inicial y que terminaba en la nueva ventana, con
los cambios ocasionados por el evento.
Con la nueva interfaz se realizaban entrevistas con usuarios para evaluar su usabilidad. A los
usuarios se les planteaban tareas que tenían que resolver haciendo uso de la interfaz. Las repuestas
dadas 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 con
los usuarios. Esta nueva interfaz se consideraba como denitiva, y era la que se usaba como guía
para la implementación.
No obstante, las pruebas de usabilidad se siguieron realizando mientras se programaba la
aplicació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, sin
pasar 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 interfaz
de forma que quedase lo más aproximada posible al dibujo realizado. Esto no siempre era
posible debido a dicultades del lenguaje de programación o de la librería de desarrollo
utilizada.
Como ayuda para renar la interfaz a desarrollar según los comentarios de los usuarios
cuando se la enseñaba. Si éstos hacían alguna observación o sugerencia sobre cómo mejorar
la interfaz, el dibujo de la misma se modicaba en consecuencia para dar respuesta a las
nuevas necesidades. Esto lo hacía siempre y cuando lo que pidiesen los usuarios no fuese a
ser muy complicado de implementar, ya que en caso de serlo no se tenía en cuenta en el
dibujo.
Más allá de esas dos utilidades, los dibujos realizados no tenían ni siquiera valor documental
una 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 de
forma que quedase lo más aproximada posible al dibujo realizado.
Como muestra del programa a lo usuarios, para que éstos vieran el comportamiento de
la versión limpia aplicación a desarrollar. Para ellos se les presentaba a los usuarios las
pantallas del diseño realizado en Microsoft Paint, y se les pedía que realizasen tareas típicas
de manejo del programa. El usuario tenía que indicar sobre qué elementos interactuaría para
conseguir el objetivo. En caso de que en una de esas interacciones se tuviera que abrir otra
ventana, el entrevistado abría el dibujo de Microsoft Paint de la ventana correspondiente
y 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 indicaba
al usuario, verbalmente, lo que sucedía si interactuaba con determinados elementos de la
interfaz.
Usuario/a 3
Cuando trabaja con Visual Basic no usa dibujos previos que describan la interfaz a desarrollar 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 usuarios, ya que las interfaces de las aplicaciones que realiza con este lenguaje son para consumo
propio. El dibujo realizado le sirve únicamente para encajar los elementos de la interfaz en
una estructura de Panels de Java SWING.
98APÉNDICE B. ENTREVISTAS REALIZADAS A DISEÑADORES PARA LA ADQUISICIÓN DE REQUISITO
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 les
planteaban preguntas sobre la misma. Las respuestas a estas preguntas servían para dictaminar si la interfaz tenía algún aspecto mejorable, el cual en caso de existir se apuntaba
para 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 la
implementación.
Usuario/a 5
El entrevistado no hizo ningún dibujo como prototipo de interfaz por las razones expuestas
en 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 denitivo, éste se usaba como guía para la implementació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 les
planteaban tareas a realizar sobre la misma. Las respuestas a estas preguntas servían para
dictaminar 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 la
implementación.
Comentar la mayor dicultad encontrada durante el proceso de
desarrollo de la interfaz por parte del diseñador
Usuario/a 1
La mayor dicultad 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 dicultad consistía en escribir el código que implementaba la interfaz
(usaba C++), y, sobre todo, el correspondiente a algunas callbacks complejas (tampoco se acuerda
de cuáles, pero sí que las de cambiar de una ventana a otra y similares podía programarlas él
mismo sin dicultades).
99
Usuario/a 3
Su mayor dicultad en Visual Basic tiene que ver con el hecho de que los widgets que
sitú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 correcta
mediante el entorno de desarrollo. La entrevistada comentó la anécdota de que la mañana
del día de la entrevista se había pasado buena parte de la jornada tratando de solucionar
ese problema.
Su mayor dicultad en Java SWING el mayor problema es situar los elementos de la interfaz
en 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 dicultad encontrada fue la generación del código correspondiente a la interfaz, no
por 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, la
programación de la interfaz no le resultó complicada, excepto por algunos problemas de comunicación entre objetos de la interfaz (del tipo de que un elemento esté anidado en otro, y deban
comunicarse adecuadamente para transferir comportamientos).
Algo que le resultó tedioso fue la programación de una interfaz multiresolución, es decir que
tuviera la misma apariencia en pantallas con distinta resolución (distinto dpi), para lo que tuvo
que 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 no
liberaba memoria lo sucientemente rápido y había que asignar punteros a null para que la
reserva de memoria no creciera excesivamente.
Usuario/a 6
Lo más dicultoso fue programar la aplicación, no por el uso de C++ sino por la FLTK. Le
costó especialmente la programación correcta de los tratamientos de eventos. No obstante, lo más
dicultoso fue encontrar el nombre de las clases que implementaban los widgets que necesitaba
en su interfaz, para lo que tenía que consultar continuamente la documentación de FLTK e ir
probando qué clase representaba qué widget.
Usuario/a 7
La mayor diculta encontrada fue diseñar una interfaz lo más usable posible: la entrevistada
encontró bastantes problemas en conseguir diseñar una interfaz que cumpliese su objetivo y que
tuviera un uso intuitivo.
La implementación no le supuso problemas porque encontró la mayor parte del código que
necesitaba para su programa en páginas web.
100APÉNDICE B. ENTREVISTAS REALIZADAS A DISEÑADORES PARA LA ADQUISICIÓN DE REQUISIT
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 interfaz de usuario usando la librería FLTK). Aunque le hubiera gustado usarla porque se daba
cuenta 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 funcionamiento
correcto del mismo ya tenía la mitad de la interfaz programada a mano y ya fue tarde para
usarlo.
Usuario/a 2
El entrevistado conocía la existencia de FLUID. Decidió no usarla para desarrollar la interfaz
porque el código que generaba no le gustaba por su aspecto descuidado. Si el código generado por
esta aplicación hubiera sido de calidad, sí que la hubiera usado, ya que una de las limitaciones
que 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 aprender
a programar determinados aspectos de la interfaz y aprender el funcionamiento básico del código
correspondiente que implementaba esos aspectos.
Usuario/a 3
Como ya se ha dicho, usa el entorno de desarrollo de Visual Basic. Le gustaría además
que existiese un entorno visual similar para usar con Java SWING, ya que reconoce que lo más
complicado 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 generaba
no le gustaba.
Usuario/a 5
El entrevistado, en referencia al uso que le dio al entorno visual de Visual Studio, ha comentado: perder el tiempo haciendo una interfaz no debería estar permitido. Las cosas que se pueden
hacer automáticamente no debería hacerlas el programador. Esto deja bastante claro que le
gusta 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ás
que para situar las cosas sobre la ventana y obtener así sus coordenadas. FLUID no le facilitaba
la tarea de implementación: el código que generaba era malo le dicultaba la tarea más que
solucionársela.
Usuario/a 7
La entrevistada se enteró de la existencia de FLUID cuando tenía el proyecto muy avanzado
y 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 herramienta 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 interfaz
es secundario para el entrevistado, ya que según él éstos podrían imaginarse el funcionamiento de la interfaz simplemente con dibujos simples sobre un papel y breves comentarios
explicativos sobre ellos.
Usuario/a 2
Le gustaría que la propia interfaz de la aplicación fuese buena: funcional y fácil de usar. Le
gustaría que la herramienta le descargara de realizar la mayor cantidad de trabajo posible pero
que a la vez le diera la posibilidad de modicar todo aquello que hubiera hecho automáticamente
la 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 la
interfaz 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 generase
un 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ón
o qué tipo de lista de elementos) es aquél en el que se está pensando poner, y no tener que
navegar por una lista de widgets de la documentación. Es decir, que la aplicación dispusiese
de 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 tipo
Microsoft Paint, que le permitiera dibujar los elementos de la interfaz en cualquier lugar de la
misma. Además, algo muy importante sería que permitiese dar funciones de comportamiento a
los elementos y denir sus eventos asociados.
102APÉNDICE B. ENTREVISTAS REALIZADAS A DISEÑADORES PARA LA ADQUISICIÓN DE REQUISIT
Apéndice C
Ejemplo de código generado por la
aplicación HandStroke
A continuación se lista el código generado para una interfaz de aplicación sencilla realizada
mediante 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 la
Figura 5.11 (p. 82).
Fichero de ejemplo
Interfaz.h,
de denición de la clase de la in-
terfaz
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
<FL/Fl_Menu_Item.H>
<FL/Fl_Button.H>
<FL/Fl_Box.H>
<FL/Fl_Text_Editor.H>
<FL/Fl_Text_Buffer.H>
<FL/Fl_Round_Button.H>
<FL/Fl_Check_Button.H>
<FL/Fl_Multiline_Input.H>
<FL/Fl_Choice.H>
<FL/Fl_Input.H>
<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. EJEMPLO DE CÓDIGO GENERADO 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.dev
Name=Interfaz
UnitCount=3
Type=0
Ver=1
ObjFiles=
Includes=
Libs=
PrivateResource=
ResourceIncludes=
MakeIncludes=
Compiler=-DWIN32 -mms-bitfields
CppCompiler=
Linker=-lfltk -lole32 -luuid -lcomctl32 -lwsock32 -lm
IsCpp=1
Icon=
ExeOutput=
ObjectOutput=
OverrideOutput=0
OverrideOutputName=
HostApplication=
Folders=
CommandLine=
UseCustomMakefile=0
CustomMakefile=
IncludeVersionInfo=0
SupportXPThemes=0
CompilerSet=0
CompilerSettings=
106APÉNDICE C. EJEMPLO DE CÓDIGO GENERADO POR LA APLICACIÓN
[Unit1]
FileName=C:\codigo\Interfaz_main.cpp
CompileCpp=1
Folder=Interfaz
Compile=1
Link=1
Priority=1000
OverrideBuildCmd=0
BuildCmd=
[Unit2]
FileName=C:\codigo\Interfaz.h
CompileCpp=1
Folder=Interfaz
Compile=1
Link=1
Priority=1000
OverrideBuildCmd=0
BuildCmd=
[Unit3]
FileName=C:\codigo\Interfaz.cpp
CompileCpp=1
Folder=Interfaz
Compile=1
Link=1
Priority=1000
OverrideBuildCmd=0
BuildCmd=
[VersionInfo]
Major=0
Minor=1
Release=1
Build=1
LanguageID=1033
CharsetID=1252
CompanyName=
FileVersion=
FileDescription=Developed using the Dev-C++ IDE
InternalName=
LegalCopyright=
LegalTrademarks=
OriginalFilename=
ProductName=
ProductVersion=
AutoIncBuildNr=0
HANDSTROKE
Bibliografía
[AGA03] Agar, P., Novins, K. (2003), Polygon recognition in sketch-based interfaces with immediate 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 of
simple 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 recognizer
for hand-drawn sketches, Computers & Graphics,
29(4), 501-517.
[GEN05] Gennari, L., Burak Kara, L., Stahovich, T. (2005) Combining Geometry and Domain
29(4): 547-562.
Knowledge to Interpret Hand-Drawn Diagrams, Computers & Graphics,
[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 Computer
Interface Design, Computer,
34(3), 56-64.
[LEE07] Lee, W., Burak Kara, L., Stahovich, T. (2007), An ecient graph-based recognizer for
hand-drawn symbols, Comput. Graph.,
31(4), 554-567.
[LI05] Li, J., Zhang, X., Ao, X., Dai, G. (2005), Sketch recognition with continuous feedback
based 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, SIGCHI
Bull., 27(3), 46-90.
a edición, McGraw
[PRE05] Pressman, R. (2005), Ingeniería del Software. Un efoque práctico, 6
Hill, 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 or
Computer 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 beautication techniques,
CHINZ '05: Proceedings of the 6th ACM SIGCHI New Zealand chapter's international conference 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 junio
de 2008)
[WXW08] wxWiki (2008), WxWidgets Compared To Other Toolkits,
(http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits) (Última visita: 4
de junio de 2008)