Barbara Liskov: l'astrazione che ha reso modulare il software

Barbara Liskov ha dedicato la propria carriera a una difficoltà che accompagna ogni grande software: come modificare una parte di un sistema senza dover comprendere o riscrivere tutte le altre? La sua risposta passa attraverso interfacce precise, rappresentazioni nascoste e proprietà che i componenti devono continuare a rispettare mentre evolvono.

Da questo approccio sono nati contributi duraturi. Negli anni Settanta Liskov e il suo gruppo al MIT progettano CLU, il primo linguaggio implementato che integra direttamente l’astrazione dei dati. I suoi lavori sulle gerarchie di tipi conducono poi al principio di sostituzione che porta il suo nome. Argus, Viewstamped Replication e le ricerche sulla tolleranza ai guasti applicano infine la stessa esigenza ai programmi distribuiti su più macchine.

Dal calcolo scientifico alla complessità del software

Barbara Huberman nasce nel 1939 a Los Angeles e cresce a San Francisco. Studia matematica alla University of California, Berkeley, e nel 1961 entra alla MITRE Corporation come programmatrice, imparando tra l’altro Fortran sul lavoro.

Prosegue gli studi di informatica a Stanford sotto la guida di John McCarthy. La sua tesi, completata nel 1968, riguarda un programma di scacchi. Liskov diventa una delle prime donne negli Stati Uniti a ottenere un dottorato da un dipartimento di informatica.

Tornata alla MITRE, lavora al sistema sperimentale Venus e incontra un problema generale: nell’hardware i confini tra componenti sono visibili, mentre nel software una parte può facilmente dipendere dai dettagli interni di un’altra. Con la crescita del programma, queste dipendenze rendono ogni modifica rischiosa.

Astrazione dei dati: separare contratto e rappresentazione

Un tipo astratto è definito dalle operazioni che offre e dalle proprietà che garantisce, non dalla struttura usata internamente. Una pila può esporre operazioni come inserimento, estrazione e cima senza rivelare se usa un array o una lista concatenata.

La separazione offre tre vantaggi: il client usa un’interfaccia più piccola dell’implementazione completa; l’autore può cambiare la rappresentazione senza rompere gli utenti; le proprietà del modulo possono essere spiegate e verificate separatamente.

Il punto centrale è la barriera di astrazione: i valori del tipo possono essere creati e osservati soltanto attraverso le operazioni autorizzate. L’implementazione diventa realmente nascosta.

CLU: incorporare l’astrazione nel linguaggio

Dal 1973 il Programming Methodology Group del MIT trasforma l’idea nel linguaggio sperimentale CLU, da cluster. Un cluster riunisce la rappresentazione privata di un tipo e le operazioni pubbliche che lo manipolano.

Liskov dirige il progetto, ma CLU è un’opera collettiva con Alan Snyder, Russell Atkinson, Craig Schaffert e altri ricercatori. Il linguaggio introduce o combina tipi astratti, tipi parametrizzati, iteratori, gestione strutturata delle eccezioni, memoria automatica e oggetti accessibili per riferimento.

CLU non diventa un grande prodotto industriale, ma influenza profondamente Ada, C++, Java, C# e molti linguaggi moderni.

Dal tipo astratto al principio di sostituzione

Nascondere la rappresentazione non basta quando i tipi formano gerarchie. Se un programma si aspetta un oggetto di un tipo e riceve un sottotipo, la sostituzione deve preservare il comportamento atteso.

Nel 1987 Liskov formula una proprietà di sottotipizzazione comportamentale, poi approfondita con Jeannette Wing. Il principio di sostituzione di Liskov afferma che un oggetto di un sottotipo deve poter sostituire un oggetto del tipo base senza rendere false le assunzioni legittime del client.

Non basta quindi avere la stessa interfaccia: il sottotipo non deve richiedere di più al chiamante, promettere di meno come risultato o violare gli invarianti annunciati. Questa idea chiarisce un limite frequente della programmazione orientata agli oggetti: l’ereditarietà è robusta solo quando rappresenta una relazione comportamentale coerente.

Argus: mantenere le astrazioni nonostante i guasti

Dopo CLU, Liskov applica gli stessi metodi ai sistemi distribuiti. In un programma eseguito su più macchine, un’operazione può essere interrotta da un guasto o dalla rete. Il sistema deve comunque proteggere dati e coerenza.

Argus, sviluppato al MIT dalla fine degli anni Settanta, organizza il sistema attorno a guardians che incapsulano stato e operazioni. Le azioni atomiche raggruppano più modifiche: devono riuscire insieme oppure essere annullate.

Argus fornisce quindi astrazioni per descrivere dove si trova lo stato, quali operazioni sono protette e come recuperare dopo un errore, anticipando problemi oggi comuni nei servizi distribuiti.

Replicazione e tolleranza ai guasti

Con Brian Oki, Liskov pubblica nel 1988 Viewstamped Replication, un protocollo che mantiene copie coerenti di un servizio. Una replica primaria ordina le operazioni; se fallisce, le altre scelgono una nuova vista e continuano senza perdere decisioni già confermate.

Il progetto Thor esplora poi un database a oggetti persistenti e transazionali. Più tardi Liskov e Miguel Castro lavorano sulla tolleranza ai guasti bizantini, in cui alcuni nodi possono comportarsi in modo arbitrario.

Il filo conduttore resta quello di CLU: una componente deve offrire una garanzia comprensibile anche quando la sua implementazione è complessa, distribuita e soggetta a guasti.

Un contributo collettivo diventato infrastruttura intellettuale

Liskov riceve il premio Turing 2008 per i contributi ai fondamenti pratici e teorici dei linguaggi e della progettazione dei sistemi. CLU dipende dal Programming Methodology Group; il principio di sostituzione viene approfondito con Jeannette Wing; Viewstamped Replication nasce con Brian Oki; Argus, Thor e gli altri sistemi coinvolgono numerosi collaboratori.

Il ruolo distintivo di Liskov consiste nel mantenere un filo tra questi lavori: partire da un problema concreto, formulare l’astrazione necessaria, incorporarla in un linguaggio o sistema e valutarla attraverso un’implementazione reale.

Perché Barbara Liskov conta ancora oggi

Lo sviluppo moderno poggia su confini: API pubbliche, moduli, servizi, tipi, contratti e protocolli. Questi confini consentono a più gruppi di lavorare separatamente e a un’implementazione di evolvere senza imporre una riscrittura generale.

I lavori di Liskov ricordano però che un confine sintattico non basta. Un modulo deve nascondere i dettagli giusti, un sottotipo deve conservare il comportamento promesso e un servizio replicato deve mantenere le proprie garanzie quando una macchina scompare. L’astrazione non ignora la realtà: la contiene dietro un contratto esplicito.

Cronologia

• 1939: nascita di Barbara Huberman a Los Angeles.
• 1961: laurea in matematica a Berkeley e ingresso alla MITRE.
• 1968: dottorato in informatica a Stanford con John McCarthy.
• 1972: ingresso al MIT.
• 1973: avvio del progetto CLU.
• 1976: importante pubblicazione sui meccanismi di astrazione di CLU.
• Anni 1980: sviluppo di Argus.
• 1987: formulazione della proprietà poi nota come principio di sostituzione di Liskov.
• 1988: Viewstamped Replication con Brian Oki.
• 1994: formulazione approfondita della sottotipizzazione comportamentale con Jeannette Wing.
• 2008: premio Turing.
• 2018: IEEE Computer Pioneer Award.

Domande frequenti

Che cosa ha inventato Barbara Liskov?

Ha avuto un ruolo centrale nell’astrazione dei dati, ha diretto CLU e ha formulato la proprietà nota come principio di sostituzione di Liskov. Ha inoltre contribuito ad Argus, Viewstamped Replication e a sistemi di archiviazione distribuiti.

Che cos’è un tipo astratto di dati?

È un tipo definito dalle operazioni e dalle proprietà garantite, mentre la rappresentazione interna resta nascosta. Il client può quindi usare una pila, un insieme o una tabella senza dipendere dalla struttura concreta.

Perché CLU è importante se è stato poco usato?

Perché ha permesso di sperimentare in un linguaggio completo tipi astratti, iteratori, eccezioni e tipi parametrizzati, influenzando linguaggi successivi.

Che cosa dice il principio di sostituzione di Liskov?

Un oggetto di un sottotipo deve poter sostituire un oggetto del tipo base senza violare le proprietà su cui si basa il client. La compatibilità riguarda quindi il comportamento, non solo nomi e firme dei metodi.

Qual è il legame tra CLU e i sistemi distribuiti di Liskov?

Entrambi contengono la complessità dietro astrazioni esplicite: CLU protegge la rappresentazione di un tipo, mentre Argus e i protocolli di replicazione proteggono le garanzie di un servizio nonostante concorrenza, distribuzione e guasti.