¡Llegamos al último paso de este Tutorial! Si en algún momento del mismo te pareció que teníamos a Pier un poco relegado, es porque estábamos esperando hasta este momento para que asuma con todo su histrionismo y dominio del escenario el papel protagónico que le teníamos reservado… ¡todo llega, Pier!
La meta central de nuestro proyecto siempre tuvo que ver con la elaboración de un algoritmo que posibilite el dibujo de polígonos regulares, y ya fue alcanzada durante el trascurso de los tres pasos anteriores…
Pero lo que nos queda tratar en este 4to paso tiene también su importancia: tiene que ver con la forma en que presentaremos todo lo que puede hacer Pier ante los ojos (y manos) espectantes de los demás.
Pero lo que nos queda tratar en este 4to paso tiene también su importancia: tiene que ver con la forma en que presentaremos todo lo que puede hacer Pier ante los ojos (y manos) espectantes de los demás.
Desde ahora los usuarios de nuestro programa ya no sólo serán espectadores pasivos de la gracia y perfección del trabajo de nuestro gatuno amigo, sino que podrán interactuar con él (aunque más no sea a través del uso del teclado) —no muy distinto, después de todo, a la interacción que podés tener con muchos de tus "amigos virtuales" a partir de la invención del chat… ¿habrá un Pier del otro lado?—
¿Interactuarán los usuarios de forma correcta? ¿Podremos hacer algo si no es así? Porque si deben ingresar un número y en su lugar tipean cualquier otra cosa nuestro programa debe estar preparado para lidiar con ésto. Dicho de otra forma, Pier debe estar en condiciones de validar o no la entrada por teclado del usuario, y de ser incorrecta dar los motivos del error para posibilitar su corrección.
Resolver lo que nos queda en este 4to paso no será precisamente fácil, y requerirá de todo nuestro ingenio a la hora de anticipar situaciones posibles. Utilizaremos de manera intensiva las estructuras condicionales (ya conocidas), y necesitaremos aprender sobre el uso de otras dos herramientas que nos ofrece Scratch: el manejo de la entrada por teclado y el envío de mensajes entre los scripts existentes en el proyecto (broadcast). Y ya llegando a la finalización del tutorial discurriremos sobre otro importante recurso al momento de programar: el uso de flags (…o banderas para los amigos).
Secuencia de pasos
La secuencia de trabajo que vamos a seguir en este 4to paso será (¿resumidamente?):
- Tomar nota de la ampliación de las metas propuestas en su momento para el 3er paso del proyecto —que concernían casi exclusivamente al modo en que los polígonos debían ser dibujados—. Dado que se va a implementar una interfaz, aparecen nuevas metas sobre el accionar de Pier antes y después de la etapa de dibujo en sí.
- Dedicar especial atención a la lectura donde se anticipa la estrategia de dividir en etapas secuenciadas al proyecto general, de manera de enfrentar la mayor complejidad relativa del mismo. Dichas etapas se comunicarán a través del envío de mensajes.
- Trabajar sobre un mini-proyecto "paralelo" que nos permitirá aprender sobre la manipulación de los datos ingresados por teclado.
- Leer algunos apuntes sobre como se aplica la idea de broadcast dentro del entorno como método propuesto para el envío de mensajes entre scripts. También llegar a la comprensión de los alcances del concepto de subrutina y de su aplicación dentro de Scratch.
- Trabajar sobre otro mini-proyecto "paralelo" en donde se presentarán las dos metodologías de envío de mensajes, se remarcarán sus diferencias, y se pondrán de manifiesto las bondades del uso de las subrutinas dentro de los programas.
- Enfrentar un análisis profundo y detallado acerca de la estrategia de división en 4 etapas propuesta, donde se incluye un algoritmo que explicita el desarrollo secuencial de cada una de ellas en vínculo con la interacción del usuario, y el papel que tendrán los mensajes como forma de comunicación entre las etapas.
- Abrir alguno de los 2 proyectos generados en el 3er paso del tutorial y guardarlo con un nuevo nombre (Pier dibuja poligonos o el que se te ocurra). El mismo será la base para la elaboración de nuestro proyecto final.
- Desarrollar el script asociado a la etapa 1, donde se pondrán en juego los conocimientos adquiridos en los 2 mini-proyectos anteriores.
- Elucubrar un algoritmo de filtrado de datos de manera de validar sólo aquellos que sean números enteros mayores o iguales a 3.
- Tomar conocimiento de algunas cuestiones vinculadas al manejo de tipos de datos en Scratch, de manera de enfrentar el pasaje desde el algoritmo teórico previo hacia un script de entrada y posterior validación de datos (que es básicamente lo buscado en la etapa 2).
- Adaptar alguno de los dos algoritmos conseguidos al finalizar el 3er paso de este tutorial, para con él dar forma al script que permita cumplimentar el trabajo destinado a ser cumplido por la etapa 3 —todo lo que tiene que ver con el dibujo de los polígonos—.
- Establecer un plan para la resolución de la etapa 4, planteando en primera instancia la generación de un algoritmo donde se presuponga que el usuario no pedirá un nuevo dibujo. Luego de ello, presentar el concepto de variables/banderas como método de comunicación y de control entre scripts, de manera de que el usuario tenga forma de acceder a la petición de un nuevo dibujo de Pier.
- Concretar una primera adaptación de los scripts vinculados a la etapa 4 donde se use una bandera de señalización como forma de comunicar la petición del usuario, y afectar así la futura evolución del programa.
- Testear la implementación propuesta bajo las más variadas posibilidades de uso por parte de un usuario. Efectuar un análisis y crítica de la solución propuesta para detectar las causas de su malfuncionamiento bajo ciertas condiciones de uso. Proponer las correcciones pertinentes para sortear este problema.
- Hacer los cambios necesarios en los 2 scripts asociados a la etapa 4 de tal forma que queden reflejadas las correcciones propuestas en el ítem anterior, de nuevos auxiliados por una nueva bandera de señalización.
- Testear nuevamente el proyecto final para verificar su funcionamiento. Una vez conformes guardar esta versión definitiva.
Creo que está más que manifiesto que nos espera a todos un largo y difícil trabajo por delante, pero si te gustan los desafíos y querés aprender un montón de cosas que vas a poder volcar en tus futuros proyectos estás [querido lector o querida lectora] desde ya invitad@, tanto por Pier como por este humilde escriba, a embarcarte en una nueva aventura… el desarrollo de una sorprendente interfaz.
Interfaz Pier-usuario
En los pasos anteriores estuvimos abocados casi con exclusividad en aprovechar las habilidades de Pier como dibujante, y sólo al finalizar el 3er paso es que empezamos a pensar en cómo va a interactuar el usuario con nuestro proyecto.
Propusimos entonces una solución simple pero eficaz: nos valimos del uso de la opción deslizador que tienen todos los monitores de las variables para acceder al control sobre el valor de n sin "tocar" el programa en sí.
¿Qué necesita el usuario?
Recordemos que un usuario normal no tiene porqué conocer como "es" el algoritmo/programa para interactuar con él; debe sí tener a su alcance algún medio que le posibilite esa interacción —usando ya sea el teclado, el mouse, un micrófono, etc.—
Pero es momento de ir más allá… demos rienda suelta a nuestra imaginación para poder así mejorar la experiencia del usuario con nuestro trabajo (e incluso, quizás, ¡sorprenderlo gratamente!).
La idea será poner a Pier como la cara visible de nuestro proyecto, un presentador-anfitrión-guía (showman showcat maybe?) con la suficiente capacidad como para relacionarse con cualquier persona que desee poner a prueba sus habilidades como dibujante.
Para conseguir esto vamos a proponer ahora un conjunto de nuevas metas a cumplir —uno entre los tantos posibles—, de manera de poder así enfocar nuestra labor de aquí a lo que resta del Tutorial.
METAS SOBRE LA INTERFAZ Y SOBRE EL PROCESO DE VALIDACIÓN DE DATOS
- Al empezar la ejecución del programa Pier deberá —educadamente— presentarse y discurrir acerca de su habilidad particular en lo que concierne al dibujo de polígonos regulares. También procederá amablemente a preguntarle el nombre a su interlocutor de turno. Mientras interactúe con el usuario aparecerá con su tamaño real (100%) y en el centro del escenario.
- Acto seguido nuestro amigo deberá proponerle al usuario que ingrese un dato vinculado con la cantidad de lados que quiera que tenga el polígono a ser dibujado. Ese dato debe ser un número entero mayor o igual a 3 —¡no hay polígonos de menos de 3 lados, pibe!—.
- Si el usuario ingresa un valor numérico que no cumpla con la condición enunciada anteriormente, Pier deberá informar de esta situación al usuario, y solicitar un nuevo ingreso de dato.
- Si el usuario ingresa texto en vez de número (por ej. si escribe tres en vez de 3) también será considerado erróneo, no porque esta información lo sea sino porque no cumple con el formato necesario para que el programa funcione. Pier debe encargarse aquí también de informar al usuario de la situación, para acto seguido solicitarle un nuevo dato.
- El programa debe contemplar el hecho de que puede haber varios ingresos consecutivos de datos erróneos, y Pier debe encargarse en cada uno de estos casos de informar sobre el error en particular.
- Sólo cuando el dato ingresado sea correcto es que Pier va a realizar su dibujo. Para ello reducirá su tamaño a la mitad (50%), y deberá desplazarse a las coordenadas de inicio… el resto del trabajo ya lo conocemos porque tiene que ver con lo ya visto en el 3er paso del Tutorial.
- Una vez terminado su dibujo, Pier se correrá hacia el centro del escenario, recobrará su tamaño original y ofrecerá al usuario (por un lapso de 10 segundos) la opción de peticionar un nuevo dibujo: si pasado este tiempo no lo hace, nuestro amigo gatuno se despedirá con un saludo y se producirá la detención automática del programa.
- Desde ya, deben seguirse cumpliendo las metas sobre el dibujo de los polígonos que fueron enunciadas en los pasos anteriores (vinculadas al centrado, tamaño del lápiz, cambio de colores, etc.).
Anticipando la estrategia
Trato de imaginarme el momento en que estés leyendo todo esto de las nuevas metas, y no me extrañaría de que sientas cierto vértigo, y quizás hasta el impulso de huir de forma despavorida. Calm down! En nuestro caso —como en muchos otros casos vinculados a la programación— es posible ver el problema como una secuencia de etapas.
Estas etapas suelen ser más fáciles de identificar si tomamos en consideración que el ordenamiento temporal de las mismas es una guía que nos posibilitará encontrar una respuesta ante el aumento en la complejidad del problema (lo que no deja de ser una respuesta enmarcada en lo que se denomina pensamiento algorítmico).
Podremos pensar en una primera etapa en donde Pier se presenta ante el usuario y le comenta sobre su habilidad al momento de dibujar polígonos regulares. Esta etapa debería ocurrir una sola vez durante la ejecución del proyecto (¿para qué más?).
Una segunda etapa debería contemplar todo lo atinente al manejo de la entrada de datos que realiza el usuario, y su posterior validación. Esta etapa debe ejecutarse tantas veces como sea necesaria hasta conseguir una respuesta válida (un valor numérico para n), para que Pier pueda así dibujar la figura en cuestión.
La tercer etapa no debería presentar inconvenientes, porque tiene que ver con todo el análisis relacionado al dibujo de polígonos (que ya hicimos de modo previo a este 4to paso). Sólo faltaría ver como vincular la "respuesta" del usuario con nuestro algoritmo.
La última etapa debe ofrecer al usuario la opción de volver a usar el programa sin tener que "ejecutarlo" desde un principio. Para ello Pier retomará su diálogo con el mismo informándole de esta posibilidad, y de que tendrá unos 10 seg. para acceder a ella. Pasado este tiempo, el programa se detendrá.
Lo más importante a destacar es que mediante esta subdivisión en etapas del proyecto conseguiremos concentrarnos en la generación de algoritmos que resuelvan cada problemática particular, pensándolos (en un principio) de forma aislada al resto… de hecho este acercamiento a la resolución del problema se ve favorecido por la capacidad de Scratch de permitir asociar más de un script (o hilo de programa) a un objeto —scripts que pueden estar "corriendo" en forma simultánea o no—.
Por supuesto que tener un montón de scripts aislados no nos servirá de nada: necesitaremos que ellos puedan controlarse entre sí y que puedan "pasarse la posta" a su debido momento, de manera de turnarse la responsabilidad de tener a cargo la ejecución de una parte del proyecto.
Esta necesidad de comunicación será resuelta mediante el envío de mensajes, que es una forma (dentro de Scratch) que tienen los scripts para comunicarse entre sí.
Tenemos entonces por delante el tratamiento y estudio de 2 nuevas capacidades del entorno de programación (entrada por teclado y envío de mensajes); para cada una de ellas presentaremos sendos mini-proyectos paralelos —tal como hicimos para explicar el concepto de variables—.
Dedicaremos pues las subsiguientes páginas a explorar estas nuevas posibilidades para después avanzar a paso firme sobre la resolución de las nuevas metas propuestas en este 4to paso.
Pier, en una irreconocible actitud zen, ya nos mira con actitud contemplativa y confía en que todo esto tiene un porqué… tomemos su ejemplo y encaremos con sabiduría lo que sigue.
Última actualización: Febrero 25, 2014
No hay comentarios.:
Publicar un comentario