Les vencimos

1º Bachillerato · TIC I

Lección 23 · C · Programación

Pensamiento computacional y algoritmos

1º Bachillerato · TIC I · Decreto 40/2022 CyL

Objetivos

  1. Distinguir problema, algoritmo y programa.
  2. Descomponer el avisador del patio en entrada, proceso y salida.
  3. Comprobar que un algoritmo es finito, definido y está ordenado.
  4. Reconocer setup y loop como el esqueleto de un sketch, y el bucle de una página.
  5. Separar, con una frase, un intérprete de un compilador.

Explicación

Pensamiento computacional no es «pensar en binario». Es una forma de partir un problema hasta que cada pieza se puede encargar sin negociar el sentido. En 1º de Bachillerato el bloque C del Decreto 40/2022 pide diseñar e implementar programas: sintaxis, estructuras, depuración, multimedia e interactividad. Nada de eso arranca en la llave del lenguaje. Arranca en el algoritmo, que es anterior al JavaScript, al sketch y al Python de la Raspberry Pi.

Problema, algoritmo, programa

El problema del departamento es concreto: si en el patio meteorológico hay poca luz, el grupo de la Semana de la Ciencia no debe salir y alguien tiene que enterarse sin depender de que una persona mire al cielo. El algoritmo es la solución general, válida para cualquier lectura y no solo para «hoy está nublado». El programa es ese algoritmo escrito en un lenguaje que un intérprete o un compilador puede ejecutar. Si el algoritmo está mal, el programa correcto solo automatiza el error.

Descomponer es la primera maniobra. Aquí salen tres piezas y no conviene fundirlas. La entrada es lo que el sistema recibe y no decide: la lectura de luz y, si hace falta, el estado de un pulsador. El proceso es la regla: comparar con el umbral 500. La salida es el efecto observable: un mensaje o un LED en alto o en bajo. En la página de este curso la salida es un dibujo. En una UNO sería el pin digital 13. En una Pi, el GPIO 18 en numeración BCM. El algoritmo es el mismo; cambia el aparato que obedece.

Qué hace que un algoritmo sirva

Tiene que terminar. Un algoritmo que dice «sigue mirando el cielo» no es un algoritmo: es un deseo, y en un bucle se convierte en un programa que no devuelve el control. Tiene que estar definido: «si está oscuro» no le sirve a una máquina hasta que «oscuro» es una comparación con un número acordado. Y tiene que estar ordenado: leer la luz después de decidir el LED es decidir con un dato que aún no existe. Esas tres propiedades se comprueban leyendo los pasos en voz alta, antes de abrir el editor.

La abstracción es quedarse con lo que cambia el resultado y tirar el resto. Para el avisador importan la lectura y el umbral. No importan el color de la puerta del gimnasio ni el nombre de quien anota. Si metes esos datos en el programa, no lo haces más inteligente: lo haces más frágil. El patrón, en cambio, sí se reutiliza: la misma comparación servirá mañana para la temperatura del aula, cambiando el sensor y el umbral, no la forma del algoritmo.

De los pasos al ejecutable

El pseudocódigo de esta lección no es JavaScript ni C++. Es una convención del aula: una orden por línea, si / si no / fin, escribe para la salida, lee para la entrada. El laboratorio lo interpreta aquí mismo, sin enviarlo a un servidor. JavaScript, en el navegador, también lo interpreta un programa que ya está en tu ordenador: el motor del navegador. Un sketch de Arduino no se interpreta en la placa línea a línea como esta página. El IDE lo compila: lo traduce a código de máquina del microcontrolador y eso es lo que se graba. Compilar y interpretar resuelven el mismo problema (pasar de un texto a una ejecución) en momentos distintos. El fallo de sintaxis detiene las dos rutas. El fallo de lógica, no.

El esqueleto setup y loop

En un sketch, setup se ejecuta una vez: ahí se declaran los pines de salida, como el 13 para el LED. loop se ejecuta sin parar: leer, comparar, escribir el pin. Ese bucle infinito es deliberado en un controlador que vive enchufado. En un algoritmo de papel, el mismo bucle solo es aceptable si cada vuelta tiene una condición de salida o si el aparato está pensado para no terminar nunca, como la alarma del patio durante la tarde del acto. Conviene escribir esa decisión. Si no, «se me ha quedado colgado» y «está vigilando» se confunden.

Esta lección no pide todavía un juego ni un objeto. Pide que el avisador quepa en pocos pasos y que seas capaz de señalar cuál es entrada, cuál es proceso y cuál es salida. El interruptor de la página es la salida simulada: ON es HIGH, OFF es LOW. Cuando más adelante el programa encienda el LED solo, el gesto de la mano tiene que coincidir con lo que diría la traza. Si no coincide, no se toca el dibujo para «arreglarlo»: se revisa la condición.

Entrada proceso salida entrada luz proceso comparar salida
Entrada, proceso y salida del avisador. El mismo esquema vale para el pseudocódigo, para el loop de Arduino y para el GPIO 18 simulado.

Glosas de esta lección

Algoritmo. Secuencia finita, ordenada y definida de pasos. No es todavía un archivo.

Programa. Algoritmo escrito en un lenguaje. Aquí, pseudocódigo y, en paralelo, un sketch.

Entrada. Dato que llega de fuera: sensor o pulsador. El programa no lo inventa.

Proceso. La regla. En este hilo, comparar la luz con 500.

Salida. Efecto comprobable: texto o pin en HIGH o LOW.

Pseudocódigo. Lenguaje de aula, una orden por línea. Lo ejecuta el laboratorio, no la placa.

Intérprete. Ejecuta el texto mientras lo lee. El navegador interpreta JavaScript.

Compilador. Traduce todo el programa antes de ejecutarlo. El IDE de Arduino compila el sketch.

setup. Bloque que corre una vez al arrancar la placa. Sitio de pinMode.

loop. Bloque que se repite. Sitio de la lectura y del digitalWrite.

Ejemplos resueltos

Ejemplo 1 — Algoritmo que no termina

«Mientras haya gente en el patio, mira el cielo». No hay lectura numérica ni paso final. Se reescribe: leer luz, comparar con 500, escribir el pin, y repetir solo si el acto sigue, con esa condición escrita.

Ejemplo 2 — Salida antes que entrada

El paso 1 enciende el LED y el paso 2 lee el sensor. La primera decisión usa un valor viejo o ninguno. Se invierte el orden. En el sketch, analogRead va antes de digitalWrite dentro de loop.

Ejemplo 3 — Umbral escondido

El programa dice si (oscuro). Nadie puede trazar «oscuro» el jueves y el viernes con el mismo resultado. Se sustituye por luz < 500 y el 500 se nombra: es un acuerdo del departamento, no una constante de la naturaleza.

Decisiones de aula

Cada caso es una entrega del avisador del patio del IES Duero (Aranda de Duero). Lee la situación antes de la decisión.

1. Partir el avisador

Situación. En el cuaderno hay un solo párrafo: «el LED se enciende cuando toca».

No conviene. Empezar por el color del LED en la página web del acto.

Decisión. Escribir tres líneas tituladas entrada, proceso y salida, y solo después el pseudocódigo.

Por qué: Un párrafo que dice «el LED se enciende cuando toca» diseña la salida antes de la regla. El dibujo manda y la condición se retuerce para que el dibujo quede bonito. Hacen falta tres líneas separadas: qué entra, qué se compara y qué efecto se ve.

2. Umbral en el código

Situación. Dos personas del grupo usan 400 y 600 sin decirlo.

No conviene. Dejar el número que «queda mejor» en el ensayo de las 17:30.

Decisión. Acordar 500, escribirlo una sola vez y citarlo en la memoria.

Por qué: Si una persona usa 400 y otra 600, la misma luz da dos resultados y ya no es un algoritmo definido. Dos umbrales son dos algoritmos. El número se acuerda, se escribe una vez y se usa en el ensayo de las 17:30, no el que «queda mejor».

3. Bucle del controlador

Situación. El sketch se queda en loop y alguien cree que se ha bloqueado.

No conviene. Añadir un delay enorme para «que se vea» y dar el ejercicio por terminado.

Decisión. Explicar que loop no tiene fin porque la vigilancia no tiene fin, y anotar el periodo de lectura.

Por qué: Que el sketch se quede en loop no significa que se haya bloqueado: es la vigilancia del avisador, que no debe parar. Esconderlo con una pausa enorme solo dificulta la traza. Se explica que loop no tiene fin a propósito, y se distingue de un cuelgue.

4. Placa que no está

Situación. El grupo quiere entregar una foto de una Pi encendida y no hay Pi en el aula.

No conviene. Inventar que el navegador escribió en el GPIO real.

Decisión. Entregar la traza y el interruptor simulado, y decir que HIGH sería led.on() en GPIO 18.

Por qué: Inventar que el navegador escribió en el GPIO real enseña un programa que no se puede repetir, porque en el aula no hay Pi. La simulación, declarada, sí se puede repetir: la traza y el interruptor. HIGH sería led.on() en el GPIO 18 si hubiera placa; aquí no la hay.

El mismo avisador, en tres lenguajes

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.

Pseudocódigo

Una orden por línea. lee luz, en el laboratorio, fija la entrada simulada en 420.

lee luz
let umbral = 500
si luz < umbral
  escribe "HIGH"
si no
  escribe "LOW"
fin

Sketch Arduino UNO

setup prepara el pin 13. loop lee A0 y escribe HIGH o LOW. Esto no se graba desde la página: es el paralelo del algoritmo.

const int LED = 13;      // paralelo didáctico del GPIO 18
const int LDR = A0;      // fotorresistencia, entrada analógica
const int UMBRAL = 500;

void setup() {
  pinMode(LED, OUTPUT);  // la salida se prepara una vez
}

void loop() {
  int luz = analogRead(LDR);   // entrada
  if (luz < UMBRAL) {           // proceso
    digitalWrite(LED, HIGH);    // salida
  } else {
    digitalWrite(LED, LOW);
  }
}

Raspberry Pi, gpiozero

LED(18) usa numeración BCM. La Pi trabaja a 3,3 V. El 5 V de la UNO no se lleva a un GPIO. En esta página led.on() no se ejecuta: lo representa el interruptor.

from gpiozero import LED
led = LED(18)          # numeración BCM, 3,3 V
UMBRAL = 500

def leer_luz_simulada():
    return 420         # en el aula real, aquí iría el sensor

luz = leer_luz_simulada()
if luz < UMBRAL:
    led.on()           # HIGH
else:
    led.off()          # LOW

Traza con las lecturas del patio

HoraluzPiezaProcesoSalida
17:30420entradacomparar con 500HIGH
17:32510entradacomparar con 500LOW
17:35390entradacomparar con 500HIGH
17:41600entradacomparar con 500LOW
17:48500entradacomparar con 500LOW
18:02250entradacomparar con 500HIGH
18:15880entradacomparar con 500LOW
18:27499entradacomparar con 500HIGH

A las 17:48 la luz es 500. 500 < 500 es falso, así que la salida es LOW. Cambiar esa decisión es cambiar el algoritmo, no «ajustar el dibujo». A las 18:27, 499 sí enciende: un dígito de diferencia es una traza distinta, no un empate.

Lectura guiada

Conviene probar el algoritmo con tres entradas extremas antes de darlo por bueno: luz 0 (sensor tapado o desconectado, según el montaje), luz 500 (el empate) y luz 1023 (el techo de un analogRead de 10 bits en la UNO). Si los tres casos no tienen una frase cada uno en el cuaderno, el algoritmo solo se ha ensayado con el tiempo que hacía el día del ensayo.

La descomposición también sirve para repartir el grupo. Una persona escribe la entrada, otra la condición, otra la frase que verá el público. El programa final es la suma, pero nadie necesita saber todavía cómo se declara una función. Ese reparto es pensamiento computacional aunque el archivo tenga doce líneas.

Cuando el mismo avisador pase a la lección 30, el propósito será lúdico y habrá una cesta y una puntuación. El algoritmo de debajo no se tira: comparar con el umbral sigue siendo el proceso. Si el juego no sabe decir cuál es su entrada, no es un programa del bloque C: es un dibujo que se mueve.

Errores que se repiten

Rúbrica de esta lección

CriterioAún noEn procesoConseguidoNotable
DescomposiciónUn párrafo únicoNombra el LED y poco másSepara entrada, proceso y salidaJustifica qué dato sobra
Definición«Si está oscuro»Hay un número sin unidad ni acuerdoUmbral 500 explícitoDiscute el caso igual al umbral
OrdenLa salida va antesEl orden se entiende a mediasLeer, comparar, escribirLo mismo en sketch y en pseudocódigo
FinNo se sabe si acabaHay un bucle mudoSe explica loop o el finDistingue vigilancia de cuelgue
Honestidad del pinDice que encendió la PiNo nombra el pinGPIO 18 y D13, simuladoRecuerda 3,3 V frente a 5 V

Mini cierre

Un algoritmo cabe en entrada, proceso y salida, termina o justifica su bucle, y no depende de adivinar «oscuro». El programa vendrá después. El LED de la página solo demuestra la salida.

Comprueba

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.

1. ¿Por qué «si está oscuro, enciende» no es todavía un algoritmo ejecutable?

Respuesta. Porque «oscuro» no es una operación definida y no se dice qué se lee ni cuándo se para.

Por qué: Una máquina no comparte el contexto del patio. Hasta que oscuro es luz < 500, dos personas pueden ejecutar pasos distintos con la misma frase y las dos creer que han seguido el algoritmo.

2. En el sketch, ¿qué trabajo hace setup que loop no debe repetir sin motivo?

Respuesta. Prepara el pin de salida, pinMode del 13, una sola vez al arrancar.

Por qué: Volver a configurar el pin en cada vuelta no cambia la lógica del avisador y mezcla preparación con vigilancia. Separarlos es lo que hace legible el programa cuando el jueves falla solo la lectura.

3. ¿Qué diferencia hay, en una frase, entre el pseudocódigo de esta página y un sketch grabado en la UNO?

Respuesta. Esta página interpreta el texto al pulsarlo. El sketch se compila en el IDE y en la placa ya no está el texto, está el código traducido.

Por qué: Por eso un error de sintaxis en el IDE ni siquiera llega a la placa, y un error de sintaxis aquí ni siquiera dibuja un estado nuevo. Un error de lógica, en los dos sitios, sí llega a ejecutarse: el LED se enciende cuando no toca y no hay mensaje de error.

En la vida real

Castilla y León, sin servidor

  • En Aranda de Duero el patio del instituto oscurece antes en noviembre que en mayo: el umbral se acuerda, no se hereda del mes.
  • En un aula de Soria sin placas suficientes, la traza en papel y el LED simulado permiten corregir el algoritmo igual que en un taller con UNO.
  • Quien anota en el cuaderno de prácticas la hora y la lectura está construyendo la entrada de un programa, aunque todavía no haya archivo.
  • El tablón del pasillo puede decir «si llueve, dentro». El programa no puede: necesita la condición que el bloque A ya pedía por escrito.
Laboratorio · en esta página Abrir en pestaña →

Editor y canvas en esta página. «lee pulsador» copia el interruptor (1 encendido, 0 apagado). «lee luz» simula 420. No hay puerto serie ni placa.

GPIO 18

Simulación local · sin hardware

Raspberry Pi (BCM) · paralelo didáctico Arduino UNO D13 · pin GPIO 18

Estado del pin: LOW · LED apagado

OFF

Este interruptor es la salida del algoritmo: ON pone el pin en alto y OFF lo pone en bajo. HIGH enciende el LED (en la Pi, 3,3 V; en Arduino UNO el paralelo didáctico es digitalWrite HIGH en D13). No se envía nada fuera de esta página.

Pulsa Ejecutar. El resultado se queda en esta página.

Escribes y dibujas aquí mismo: no hay salto a otro módulo. La misma herramienta, a pantalla completa, está en l23-pensamiento-computacional-y-algoritmos.html y en el marco (útil si el navegador permite file:// en iframes).

Reto Profesor

El avisador en doce líneas

Escribe en el laboratorio el pseudocódigo del avisador con un umbral que hayas elegido y justificado en una frase del cuaderno. Tiene que haber una entrada, una comparación y una salida HIGH o LOW. Mueve el interruptor, ejecuta otra vez con lee pulsador y anota qué valor entra. Una buena entrega explica el caso en el que la luz es exactamente el umbral, y no afirma que la página haya encendido una placa.

reto_id: bach1-tic-L23