⚙️ Dai requisiti alla verifica della soluzione
Abstract. La qualità di una soluzione informatica dipende dalle decisioni che ne definiscono il comportamento. Una richiesta semplice, come eliminare i duplicati da un elenco, può nascondere criteri diversi. Occorre stabilire quali elementi siano equivalenti, quale occorrenza conservare e quale ordine rispettare. Da queste scelte derivano il procedimento, i controlli e il confronto tra strategie. Un esempio concreto permette di seguire il legame tra requisiti, codice e risorse. La progettazione diventa così un ragionamento di cui si possono discutere le conseguenze.
🔎 Le decisioni nascoste nella richiesta
Parole come «uguale», «ordinato» e «valido» possono sembrare sufficientemente precise finché non occorre tradurle in un comportamento. Eliminare i duplicati da un elenco richiede, per esempio, di decidere se due elementi debbano coincidere in tutti i campi oppure soltanto in un identificatore. Se contengono informazioni differenti, va stabilito quale conservare.
Consideriamo un caso illustrativo più semplice: una sequenza di interi nella quale vogliamo mantenere soltanto la prima occorrenza di ciascun valore, rispettandone l’ordine di apparizione. L’ingresso [7, 2, 7, 5, 2, 9] deve allora produrre [7, 2, 5, 9] . Il risultato [2, 5, 7, 9] contiene gli stessi valori distinti, ma viola il requisito d’ordine.
🧩 Rendere le scelte operative
Una strategia consiste nell’esaminare gli elementi da sinistra a destra e aggiungere all’uscita soltanto quelli non ancora incontrati. Il punto da rendere esplicito è come riconoscere un valore già presente. Confrontarlo con tutti gli elementi conservati oppure mantenere una struttura dedicata alla ricerca porta a organizzazioni diverse del lavoro.
Diagrammi di flusso e pseudocodice possono rendere visibile questa scelta prima dell’implementazione. Nel codice, la suddivisione in funzioni può separare il criterio di confronto dalla gestione dell’elenco. Se in seguito cambia il significato di duplicato, diventa più semplice individuare quali parti dipendano da quella decisione.
Pietra miliare. Nell’esempio, unicità e ordine sono due obblighi distinti. Il procedimento deve conservarli entrambi; soddisfarne soltanto uno produce una soluzione incompleta rispetto alla richiesta.
🧪 Controllare proprietà indipendenti
I controlli acquistano valore quando interrogano aspetti diversi del comportamento. Una sequenza vuota deve restare vuota; una sequenza senza ripetizioni deve mantenere tutti i suoi elementi; una sequenza di valori identici deve conservarne uno. Occorre inoltre verificare che l’uscita non introduca valori assenti dall’ingresso e rispetti l’ordine richiesto.
Esiste anche una proprietà utile: ripetere la deduplicazione sul risultato non dovrebbe modificarlo. Da sola, però, questa proprietà non basta. Un programma che restituisce sempre un elenco vuoto la soddisfa, pur eliminando dati che avrebbe dovuto conservare. Un controllo può quindi essere corretto e al tempo stesso insufficiente.
La proprietà generale della strategia può essere formulata così: dopo ogni passo, l’uscita contiene esattamente le prime occorrenze degli elementi già esaminati. Un caso ammesso che produca una perdita, una ripetizione o un ordine errato smentisce la correttezza dell’implementazione. Il successo su alcuni esempi lascia invece aperti i casi non controllati.
📏 Confrontare il costo della stessa richiesta
Una volta fissati i requisiti, possiamo confrontare strategie compatibili. Se ogni nuovo valore viene confrontato con tutti quelli già conservati, una sequenza di n valori distinti richiede n(n−1)/2 confronti : 4.950 per 100 elementi e 499.500 per 1.000 elementi.
Sono conteggi del procedimento descritto, non tempi misurati. La durata reale dipende anche dal costo di ciascun confronto e dall’ambiente di esecuzione. Una struttura ausiliaria può ridurre il lavoro di ricerca, ma introduce proprie esigenze di memoria e gestione. Valutare l’efficienza significa rendere esplicito questo compromesso.
Pietra miliare. Un controllo riguarda ciò che il programma deve restituire; un conteggio riguarda il lavoro necessario per ottenerlo. Il confronto delle prestazioni resta significativo soltanto a requisiti e ipotesi dichiarati.
🔗 Implicazioni e connessioni interdisciplinari
Nelle basi di dati, scegliere un solo elemento per identificatore può significare decidere quale versione di un’informazione conservare. Nella logica matematica, il criterio di uguaglianza permette di raggruppare elementi equivalenti e scegliere un rappresentante. Nell’ingegneria del software, isolare tale criterio consente di riconoscere le conseguenze di una modifica. Lo stesso problema mette quindi in relazione significato dei dati, proprietà formali e manutenzione del programma.
⚖️ Limiti, incertezze e domande aperte
L’esempio assume un elenco finito, immutato durante l’elaborazione, e un confronto esatto tra interi. Record incompleti, informazioni contraddittorie o somiglianze approssimate richiedono criteri ulteriori. Due elementi molto simili non sono necessariamente duplicati, e la prima occorrenza non è necessariamente quella più aggiornata.
La scelta del rappresentante resta quindi legata allo scopo. Un procedimento può rispettare perfettamente la specifica e conservare informazioni poco utili se il requisito iniziale era inadeguato. La verifica dell’implementazione e la valutazione della richiesta rispondono a domande differenti.
🧭 Sintesi
Nel caso dei duplicati, progettare una soluzione significa collegare criterio di uguaglianza, scelta dell’occorrenza, ordine, controlli e risorse. Il programma realizza un insieme di decisioni riconoscibili. La qualità del progetto emerge dalla coerenza tra quelle decisioni e il comportamento effettivamente ottenuto.