El diagrama de flujo es el algoritmo dibujado para que el orden se vea de un golpe. No sustituye al pseudocódigo: lo comprueba. Si no puedes dibujarlo, normalmente es porque un paso esconde dos decisiones o porque una flecha vuelve atrás sin condición. El bloque C pide las dos escrituras. Esta lección las pone en la misma página: el editor es el pseudocódigo y el canvas es el diagrama.
El óvalo es inicio o fin. No lleva una cuenta dentro: solo marca que el recorrido empieza o que se devuelve el control. El rectángulo es un proceso: una asignación, una cuenta, guardar un umbral. El rombo es una decisión y por eso tiene dos salidas, aunque en un dibujo pequeño a veces solo se lea el texto de la pregunta: el sí y el no tienen que existir en el pseudocódigo como si y si no. El paralelogramo es entrada o salida: leer el sensor o escribir el mensaje. La flecha no es decoración: sin flecha, el orden es el que cada cual imagine.
Hay símbolos que este curso no necesita todavía: el cilindro de un disco, la cinta de un documento impreso, el rectángulo con rayas de una función predefinida. Meterlos «porque salen en un póster» no hace el diagrama más correcto. Hace falta el rombo el día en que hay una condición, y sobra el rombo el día en que el paso es solo una suma.
La regla de traducción del laboratorio es estable, para que puedas discutirla. inicio y fin se vuelven óvalos. Una línea que empieza por si, mientras o para se vuelve rombo. escribe y lee se vuelven paralelogramos. devolver y funcion se marcan aparte, de otro color, porque todavía no son el tema central: llegarán con las funciones. El resto de las órdenes son rectángulos. fin de un bloque, si no y else se dibujan como un nudo pequeño: no son un proceso nuevo, son el cierre del camino.
Esa traducción automática es un criterio de aula, no una norma ISO que debas citar de memoria. Sirve para pillar el fallo gordo: un programa con un si y ningún rombo en la cabeza de quien lo escribe; o un diagrama con un rombo cuyo texto no cabe en una pregunta de sí o no. Si tu línea dice «hacer lo correcto», el canvas pintará un rectángulo o un rombo según la primera palabra, pero el algoritmo seguirá sin estar definido. El dibujo no piensa por ti.
«Leemos el sensor y si vemos que está bajo encendemos y si no lo dejamos» es una frase de memoria, no un pseudocódigo. En el editor, una orden por línea, la condición sola en el si, y un fin que cierra. La sangría ayuda al ojo y el laboratorio no la exige: exige el fin. Cuando pases este texto a un sketch, el si se parece al if, el fin se parece a la llave que cierra, y el paralelogramo de salida se parece a digitalWrite. El óvalo de inicio, en Arduino, es el arranque de la placa, no una línea que tú escribas dentro de loop.
Un mientras es un rombo cuya flecha de sí vuelve al cuerpo y cuya flecha de no sale. En el canvas de esta lección las flechas bajan en el orden del texto, para no convertir el dibujo en un enredo imposible de seguir en un móvil del aula. En el cuaderno, si dibujas a mano el mientras de «repetir mientras el acto siga», marca la vuelta. Lo que no puedes hacer es una flecha que vuelve sin decir en qué condición. Eso es un bucle infinito disfrazado de esquema.
El interruptor entra en el diagrama cuando la línea es lee pulsador. Encendido, la entrada vale 1; apagado, vale 0. Puedes añadir un segundo rombo: si pulsador es 1, no se avisa aunque haya poca luz, porque alguien del departamento ha decidido silenciar el LED durante la foto de grupo. Dos rombos son dos decisiones. Fundirlas en «si está oscuro y nadie ha pulsado» sin dibujarlas es la manera más rápida de no saber, el jueves, cuál de las dos falló.
Óvalo. Inicio o fin. No es un proceso con cuenta dentro.
Rectángulo. Proceso: asignación o cálculo. Una entrada, una salida.
Rombo. Decisión. La condición debe poder ser sí o no.
Paralelogramo. Entrada o salida: lee o escribe.
Flecha. El orden. Si falta, el diagrama es una lista de pegatinas.
si no. El camino del no. En el dibujo manual sale del rombo; en el texto, es una línea propia.
fin. Cierra si, mientras, para o funcion. Sin fin, el diagrama no sabe hasta dónde llega el sí.
Traducción. Misma lógica, otra sintaxis. El if del sketch es el rombo, no el óvalo.
El dibujo pregunta «¿luz < 500?» y solo tiene flecha hacia HIGH. El caso 510 no existe. Se añade el camino LOW, que en pseudocódigo es el si no.
Alguien escribe «inicio: luz = 420» dentro del óvalo. Se saca la asignación a un rectángulo debajo de inicio. El óvalo solo abre.
Hay un paralelogramo que dice «pensar». Pensar no es una entrada ni una salida. O es un rectángulo con una cuenta concreta, o se borra.
Cada caso es una entrega del avisador del patio del IES Duero (Aranda de Duero). Lee la situación antes de la decisión.
Situación. Todo el avisador está en rectángulos, también la pregunta.
No conviene. Porque así es más rápido de dibujar con la regla.
Decisión. Pasar la comparación a un rombo y dejar la asignación del umbral en un rectángulo.
Por qué: Si la pregunta también va en un rectángulo, quien lee el diagrama no ve dónde se bifurca sin leer el párrafo de la memoria. El rombo existe para eso. Pasar la comparación al rombo no es decorar: es hacer visible el sí y el no.
Situación. El esquema vuelve al inicio «por si acaso».
No conviene. Dejarla porque el loop de Arduino también se repite.
Decisión. Sustituirla por un mientras con la condición escrita, o explicar que el óvalo de fin devuelve a loop solo en la placa.
Por qué: Una flecha que vuelve al inicio «por si acaso», sin condición, es un algoritmo que en el papel no termina. En la placa, loop ya es el sitio de la repetición y se nombra. En el diagrama se sustituye por un mientras cuya condición se pueda señalar.
Situación. El rombo dice «si está nublado o el profe lo indica o es última hora».
No conviene. Encoger la letra hasta que quepa.
Decisión. Partir en dos o tres rombos, cada uno con una pregunta cerrada.
Por qué: Un rombo con tres motivos («nublado o el profe o última hora») no se puede trazar: cuando falla, no sabes cuál era cierto. Encoger la letra no lo arregla. Se parte en decisiones de una sola pregunta, cada una con su sí y su no.
Situación. El grupo entrega solo la captura del canvas.
No conviene. Porque el botón ya dibuja.
Decisión. Entregar también el pseudocódigo del editor, que es la fuente.
Por qué: El canvas de esta página es una vista del texto, no la entrega. Si el pseudocódigo está mal, el dibujo elegante sigue estando mal. Se entregan las dos cosas: el texto que se puede leer en voz alta y la captura que lo refleja.
El problema no cambia: si la luz del patio del IES Duero baja de 500, hay que avisar. Cambia quién ejecuta. El pseudocódigo lo ejecuta el laboratorio de esta página. El sketch lo compilaría el IDE de Arduino hacia la UNO. El fragmento de Python lo ejecutaría una Raspberry Pi con gpiozero, si hubiera placa. Aquí no hay placa.
inicio y fin: óvalo. lee y escribe: paralelogramo. si: rombo. la asignación: rectángulo.
inicio
lee luz
let umbral = 500
si luz < umbral
escribe "HIGH"
si no
escribe "LOW"
finNo hay óvalo dentro de loop: el inicio de la placa ya ocurrió. El if es el rombo.
void loop() {
int luz = analogRead(A0); // paralelogramo de entrada
if (luz < 500) { // rombo
digitalWrite(13, HIGH); // paralelogramo de salida
} else {
digitalWrite(13, LOW);
}
}Dos condiciones, dos rombos si lo dibujas bien. El 23 no es el pin del LED. En la página, el segundo dato es el interruptor simulado, no un Button real.
from gpiozero import LED, Button
led = LED(18)
pausa = Button(23) # otro GPIO, no el 18
luz = 420
if luz < 500 and not pausa.is_pressed:
led.on()
else:
led.off()
| Hora | luz | Símbolo | Camino | Salida dibujada |
|---|---|---|---|---|
| 17:30 | 420 | rombo | sí, HIGH | paralelogramo |
| 17:32 | 510 | rombo | no, LOW | paralelogramo |
| 17:35 | 390 | rombo | sí, HIGH | paralelogramo |
| 17:41 | 600 | rombo | no, LOW | paralelogramo |
| 17:48 | 500 | rombo | no, LOW | paralelogramo |
| 18:02 | 250 | rombo | sí, HIGH | paralelogramo |
| 18:15 | 880 | rombo | no, LOW | paralelogramo |
| 18:27 | 499 | rombo | sí, HIGH | paralelogramo |
Cada fila es una ejecución distinta del mismo diagrama, no un diagrama nuevo. El rombo no cambia: cambia el dato que entra por el paralelogramo. Si para 510 y para 420 dibujas dos esquemas distintos, estás copiando resultados, no el algoritmo.
Dibuja a mano, en el cuaderno, el caso 500 al lado del rombo y escribe en el camino del no la palabra LOW. Esa anotación no sale en el canvas y es precisamente la que demuestra que has mirado el empate. El laboratorio no puntúa la letra: puntúa que el texto tenga si no.
Si anidas un si dentro de otro, el diagrama crece a lo ancho. En el canvas verás dos rombos seguidos hacia abajo. En el papel, sepáralos en horizontal solo si de verdad salen dos caminos vivos. No abras un camino que el pseudocódigo no tiene.
El óvalo de fin, en un programa de consola, es el final del proceso. En el avisador de la placa no apagas el microcontrolador al terminar una lectura: vuelves a loop. Por eso el pseudocódigo de una sola pasada y el sketch de vigilancia no se calcan línea a línea, y hay que decir cuál de los dos estás escribiendo.
| Criterio | Aún no | En proceso | Conseguido | Notable |
|---|---|---|---|---|
| Símbolos | Todo rectángulos | Mezcla óvalo y proceso | Usa óvalo, rombo, dato y proceso | El sí y el no se leen sin leyenda |
| Coherencia | El dibujo no es el texto | Se parecen | Cada línea tiene su símbolo | El caso umbral está en el no |
| Cierre | No hay fin | fin de más | Cada si tiene su fin | Anidado legible |
| Placa | No se relaciona | Dice «es lo mismo» sin señalar | if es el rombo, digitalWrite la salida | Distingue loop de flecha muda |
| Canvas | Captura sin texto | Texto sin dibujo | Los dos, de esta página | Señala un símbolo que corregiría a mano |
Si el rombo no cabe en una pregunta de sí o no, el paso no está definido. El canvas obedece al texto: corrige el editor, no el dibujo a mano alzada encima.
Abre cada pregunta, responde en el cuaderno y después mira la solución. El párrafo «Por qué» es la parte que se estudia.
Respuesta. Porque no bifurca: tiene una entrada y una salida.
Por qué: El rombo obliga a imaginar un sí y un no. En umbral = 500 no hay nada que contestar. Ponerlo en rombo enseña a leer mal todos los diagramas siguientes, incluidos los de un if de verdad.
Respuesta. digitalWrite es salida, paralelogramo. if es decisión, rombo.
Por qué: digitalWrite es una salida y en el diagrama va en paralelogramo, no dentro de la pregunta. if es la decisión y va en rombo. Mezclarlos hace que el esquema «encienda» dentro de la pregunta, y entonces no se puede señalar el paso que falla cuando el LED no coincide con la traza.
Respuesta. La flecha de vuelta y la condición del rombo, que el texto ya debe contener.
Por qué: La vista de esta página prioriza el orden de lectura en pantalla. No te libera de marcar la repetición cuando el algoritmo vuelve. Si el mientras no está en el texto, dibujarla a mano sería inventar un bucle que el programa no tiene.
En la vida real
Escribes y dibujas aquí mismo: no hay salto a otro módulo. La misma herramienta, a pantalla completa, está en l24-diagramas-de-flujo-y-pseudocodigo.html y en el marco (útil si el navegador permite file:// en iframes).
Deja en el editor un pseudocódigo con inicio, una lectura, un si con si no y fin. Dibuja el diagrama en el canvas y, en el cuaderno, copia solo el rombo con las dos salidas escritas (HIGH y LOW), incluido el caso igual al umbral. Una buena entrega no tiene flechas huérfanas ni un proceso metido dentro del óvalo.
reto_id: bach1-tic-L24