4to paso: diseñar una interfaz (parte V)

¿Te sumergiste en la relectura que te sugerí al finalizar la página anterior? Espero que sí, porque —ya contando con casi todas las herramientas conceptuales y funcionales en nuestras manos— nos queda lo más difícil: debemos ser capaces de ver el proyecto en su totalidad, y necesitaremos establecer una estrategia de resolución pensando, sobre todo, en el usuario que va a disfrutar de nuestro trabajo.
Es por eso que estamos dedicando todo este 4to paso al diseño de una interfaz: ya conseguimos darle a Pier los elementos para que pueda dibujar cualquier polígono regular, ahora deberemos darle un guión para que pueda ser la cara visible del proyecto y también sea capaz de interactuar directamente con el usuario.
Esto abarcará la posibilidad de tener que enfrentarse con el hecho de que el usuario pueda ingresar un dato erróneo (consideraremos erróneo a todo dato que NO SEA un número entero mayor o igual a 3)… Pier deberá poder lidiar con esa situación y estar capacitado para corregirlo todas las veces que sea necesario.
Arranquemos pues con un análisis más profundo sobre la estrategia ya enunciada en su momento, basada en una división en etapas y en la comunicación entre ellas utilizando una potente herramienta de programación: el envío de mensajes.

Algoritmos y estrategias

Ya hicimos una descripción sobre el trabajo que le iba a ocupar a cada etapa, pero seguramente no quedó suficientemente clara la mirada algorítmica que va a terminar de explicitar nuestra estrategia de resolución del problema, especialmente en lo que al ordenamiento temporal se refiere.

La lógica algorítmica es muy particular, y requiere de algún tipo de simbología para poder expresarse. Una de las formas de representar un algoritmo es a través de lo que se llama diagrama de flujo: allí se utiliza un conjunto de símbolos con significados bien definidos que representan los pasos del algoritmo, y donde además se necesitan flechas que representen el flujo de ejecución a seguir.

La imagen que seguramente ya captó tu atención es la de un diagrama de flujo que explicita cual es la secuencia temporal en que deberán actuar cada una de las 4 etapas de nuestro proyecto.
Desde lo visual ya queda de manifiesto una diferencia entre las etapas 1 y 3 del proyecto respecto a las etapas 2 y 4:
  • en las primeras se verificará que una vez ejecutados los algoritmos/programas que las componen se pasa de manera indefectible a la etapa subsiguiente,
  • en las segundas está explícito que el flujo vinculado a la secuencia de ejecución de las etapas puede seguir un camino u otro, dependiendo esto de que una determinada condición se cumpla o no.
diagrama de flujo
Para la etapa 2 la condición bajo análisis es el dato ingresado por el usuario: sólo si es correcto es que se pasa a la etapa 3, de lo contrario el flujo queda dirigido hacia sí misma quedando constituído un bucle del que sólo puede salirse con la entrada de un dato que pase la validación.
En la etapa 4 también hay una decisión involucrada, pero en este caso se agregará un factor temporal: la condición a ser analizada aquí es si el usuario opta por pedir un nuevo dibujo a Pier dentro de los 10 segundos pautados para indicar su decisión. Si se cumple, el flujo será redirigido al inicio de la etapa 2 , de lo contrario se finalizará el programa.

El papel de los mensajes

Creo conveniente dejar explicitada una conclusión que no por obvia deja de ser importante: salvo la etapa 1 , las 3 restantes pueden potencialmente ser ejecutadas más de una vez durante el transcurso del proyecto (todo esto dependiendo de la acción del usuario).
Repasemos algo dicho en la página anterior, cuando discurrimos sobre las ventajas de separar un proyecto en varios scripts:

"Hay un aspecto más general que justifica la existencia de scripts dedicados a labores específicas: la posibilidad de reutilización de los mismos por parte de cualquiera de los otros scripts del proyecto, invocándolos a través del envío de un mensaje. Esto permite una mejor organización del programa…", etc.

De nuevo aparece el eco de la idea de subrutina de la que tanto ya hablamos… aunque cuando se trata de Scratch y de sus múltiples hilos de ejecución yo me inclino a pensar en término de etapas y no de subprogramas que son invocados desde un programa principal (¡he dicho!).

¿Qué función cumplirán los mensajes dentro de este esquema? 

El papel del envío de mensajes será el de permitir plasmar en el programa el flujo de ejecución planificado en el algoritmo y mostrado en el diagrama de flujo (podemos decir que tienen relación directa con las flechas dibujadas en el mismo).
Y ya que hablamos de este diagrama de flujo, fijate que están indicados a modo de guía los nombres que les daremos más adelante a dichos mensajes —es lo indicado en color rojo—. Como podés apreciar son 3: validar, dibujar y repreguntar.

Del satélite a la lupa

Hice mi mejor intento para ofrecer la mirada más abarcativa sobre el funcionamiento del proyecto a la que pude llegar… esto requirió que nos olvidásemos por un rato de juntar bloquecitos para pasar a pensar algorítmicamente en término de unidades o etapas de las que aún, curiosamente, no tenemos mucho más que el conjunto de especificaciones que ellas deben cumplir.
Esta mirada global tiene mucho de abstracta, pero si conseguís lograr cierto dominio sobre ella te facilitará el desarrollo de proyectos más y más complejos… por ello te sugiero que le des importancia al tema tratado en esta página más allá del alcance de este Tutorial sobre dibujo de polígonos regulares.
Una vez dicho esto, embarquémonos pues lupa en mano para focalizar ahora nuestra mirada en el desarrollo de cada una de las 4 etapas en las que dividimos nuestro proyecto. ¡Hacia allí vamos!
Última actualización: Marzo 1, 2014

No hay comentarios.:

Publicar un comentario

© Scratch CodeLab | D153ñ0 b454d0 3n l4 pl4n71ll4 SimpleRWD d3 Oloblogger