
Ripasso di inizio anno – appunti per la classe.
Perché bisogna imparare a realizzare i diagrammi di flusso (anche se “programmiamo poco”)?
Quando progetti un programma per Arduino, il problema più grande non è scrivere le parentesi giuste: è decidere l’ordine delle azioni e quando prendere decisioni. Un diagramma di flusso è un disegno semplice che mostra i passi da compiere, le scelte “sì/no” e l’ordine in cui tutto accade. È usato in informatica da decenni proprio per rappresentare, passo-passo, il comportamento di un algoritmo o di un processo.
Un flowchart ti aiuta a vedere il programma prima di scriverlo: rettangoli per le azioni (es. “accendi LED”), rombi per le domande (es. “pulsante premuto?”), ovali per inizio/fine, parallelogrammi per ingresso/uscita di dati, frecce per la direzione. L’idea è sempre quella: dall’alto verso il basso, una freccia alla volta, fino all’uscita. Questa notazione è diventata uno standard di fatto e, nelle versioni “complete”, include molte altre forme utili (ne esistono decine); noi useremo solo quelle essenziali.
Dove si usano e perché ci interessano in laboratorio di sistemi
I diagrammi di flusso non servono solo a chi programma: si usano per documentare, spiegare e migliorare processi in tanti contesti (scuola, aziende, sanità, logistica). Nel nostro laboratorio li usiamo per tradurre un problema reale (una luce che si accende, un sensore che decide) in una sequenza chiara. Questo approccio è lo stesso che trovi nel project management: rappresentare un processo rende più facile pianificare, allineare il team e trovare i colli di bottiglia.
Esistono poi varianti “cugine” dei flowchart che potresti incontrare:
- Workflow (flusso di lavoro), molto usato per capire chi fa cosa e quando;
- Swimlane (corsie), utile quando più persone o sottosistemi collaborano;
- Data Flow Diagram / DFD (flusso di dati), focalizzato su come circolano i dati tra parti di un sistema.
Noi partiamo dal flowchart di base (azioni/decisioni) perché è il ponte più diretto verso il codice Arduino
Buone pratiche “da prima riga di codice”
- Definisci il problema in una frase (“Cosa voglio ottenere?”).
- Elenca i passi e le decisioni (domande “sì/no”).
- Disegna il flusso con poche forme standard (Inizio > Azioni > Decisioni > Fine).
- Cerca le inefficienze: passaggi inutili, decisioni doppie, attese esagerate.
- Condividi e rivedi: il diagramma è un documento vivo; aggiornatelo quando cambi idea.
Questa routine è identica a quella usata nei team professionali quando costruiscono o migliorano un processo.
Dalla carta al digitale (e al testo)
Puoi disegnare su carta, usare strumenti visuali come Lucidchart o Miro (trascini le forme e colleghi con frecce), oppure scrivere i diagrammi come testo con Mermaid (“diagram as code”), che si integra bene nei siti e nelle note tecniche. In questa lezione useremo Mermaid proprio per abituarci a ragionare prima in blocchi, poi in pseudocodice, poi in C/C++ per Arduino.
Mappa veloce “flowchart > Arduino”
Inizio / Setup > setup(): qui imposti i pin come INPUT/OUTPUT.
Azione → istruzioni come digitalWrite(), analogWrite(), tone().
Decisione (rombo) > if (...) { ... } else { ... }, spesso con letture da sensori: digitalRead(), analogRead().
Ciclo > loop() che ripete le azioni in sequenza.
Questa corrispondenza 1:1 rende naturale “tradurre” il disegno in codice, riducendo gli errori e il tempo di debug. (Rivedremo questa mappa in ogni esempio pratico.)
Cosa evitare all’inizio
- Frecce che si incrociano: rendono il percorso confuso.
- Domande ambigue: un rombo = una domanda con risposta sì/no chiara.
- Simboli inventati: resta su 4–5 forme standard; andrai veloce e capirai tutto al volo.
- Salti di logica: se ti perdi, torna ai passi del processo (definisci > elenca > disegna > verifica).
Un buon diagramma di flusso è come una ricetta: indica ingredienti (sensori/attuatori), passaggi (azioni), domande al cuoco (“la pasta è al dente?” > sì/no). Se la ricetta è chiara, il codice funziona e tutti in team capiscono cosa fare.
Nota per i lettori (studenti e non): nei paragrafi successivi troverai la pipeline completa che useremo sempre: Problema > Diagramma (Mermaid) > Pseudocodice > Sketch Arduino, con esempi concreti (LED, pulsante, LDR, buzzer). Questa struttura è pensata per classi che iniziano: potete seguirla anche se non hai mai scritto una riga di codice.
Simboli nei diagrammi di flusso: poche forme bastano
L’elenco delle forme può sembrare infinito, ma non serve conoscerle tutte. Ogni simbolo indica un tipo di passaggio preciso e ha un contesto d’uso ben definito. Quando disegni, se ti senti perso, torna all’essenziale: per la grande maggioranza dei diagrammi bastano davvero alcune forme base; le altre servono in casi specifici. Qui sotto trovi quelle più ricorrenti.
Forme comuni del flowchart
| Simbolo del diagramma di flusso |
Nome |
Descrizione |
 |
Inizio/Fine |
Segna il punto di avvio o la conclusione del flusso; delimita i confini del processo. |
 |
Processo / Azione |
Indica un passo operativo: un’attività, una funzione o un’elaborazione che “fa qualcosa”. |
 |
Decisione |
Rappresenta una domanda binaria (sì/no, vero/falso) che dirama il percorso su esiti diversi. |
 |
Input/Output (Dati) |
Mostra un ingresso (dato in arrivo, misura, comando) o un’uscita(risultato, messaggio, documento). |
 |
Linea di flusso |
Definisce la direzione della sequenza tra le forme; chiarisce l’ordine dei passi. |
 |
Sottoprocesso / Processo predefinito |
Collega a una procedura già definita altrove o a un gruppo di azioni consolidate. |
 |
Connettore in pagina |
Unisce parti lontane dello stesso schema senza incrociare frecce; migliora la leggibilità. |
 |
Connettore fuori pagina |
Collega a un continua su un’altra pagina; spesso include un riferimento o un codice. |
 |
Documento |
Indica la produzione o l’uso di un documento (ordine, report, lettera, promemoria). |
 |
Documenti multipli |
Come sopra, ma per più documenti generati/gestiti nello stesso passaggio. |
 |
Input manuale |
L’utente digita o inserisce dati a mano (es. login, compilazione di un campo). |
 |
Operazione manuale |
Passo che richiede intervento umano (non automatizzato) per proseguire. |
 |
Database / Archivio dati |
Dati archiviati in modo strutturato e interrogabili (lettura/scrittura/filtri). |
 |
Memoria interna |
Dati conservati all’interno del sistema/dispositivo durante l’elaborazione. |
 |
Attesa / Ritardo |
Indica una pausa temporale o un ritardo prima del passo successivo. |
 |
Commento / Nota |
Aggiunge chiarimenti al lettore; si collega con linea tratteggiata alla parte pertinente. |
Alcune varianti di forma e naming possono cambiare leggermente a seconda dello strumento o dello standard adottato; l’insieme di base rimane comunque coerente tra le principali piattaforme.
Nella prossima lezione vedremo quali tool utilizzare per disegnare diagrammi di flusso.
Buon Coding a tutti 🙂