In trent’anni l’ingegneria del software ha vissuto l’entusiasmo della nascita, la crisi della pubertà e la forza della maturità.
C’era bisogno di un metodo potente, chiaro e applicabile nei tempi previsti. Erano queste, trent’anni fa, le esigenze dei programmatori che hanno portato all’ideazione delle basi della software engineering, ovvero l’insieme dei metodi standard da seguire per la costruzione di sistemi software di grandi dimensioni. La sua storia è cominciata ufficialmente nel ottobre 1968, durante una conferenza organizzata dal comitato scientifico della Nato a Garmisch-Partenkirchen. Nello stesso momento in cui il presidente Lindon B. Johnson decise di interrompere i bombardamenti in Vietnam, gli informatici di tutto il mondo si riunirono per porre le basi del software engineering, definendone prima di tutto il concetto. A distanza di trent’anni i contenuti delle relazioni e le conclusioni portate agli atti di due conferenze (quella dell’ottobre 1968 e quella dell’ottobre 1969 svoltasi a Roma) sono ancora di straordinaria attualità. Si parla di concetti come le componenti e la loro gestione, dell’evoluzione di un modello di Software engineering e del suo riutilizzo, della nozione del ciclo di vita del software, delle difficoltà della verifica logica, dei metodi formali, dell’evoluzione di un progetto, della stima dei costi e dei ritardi e, anche dei concetti che poi sono diventati la base della programmazione a oggetti. Tutto questo era già un’esigenza trent’anni fa, ma allo stato embrionale. La maturazione sarà lunga per giungere a dei metodi di sviluppo degni di questo nome e corredati da strumenti adeguati. Nell’attesa, durante questi trent’anni, il Software engineering resta l’anello debole della catena di produzione dei grandi sistemi informatici. Debole a tal punto che, verso la metà degli anni settanta, gli informatici non esitano di parlare di una vera crisi del Software engineering. I trent’anni successivi saranno caratterizzati da una pletora di metodi per i quali è stato estremamente complesso riconoscere una tipologia comune o cercare di stabilire una verifica degna di questo nome. Bisogna aspettare il 1977 per l’arrivo di un metodo riconosciuto, la Sa (Structured Analysis), deriva dai metodi basati sul concetto di funzione, già molto noti in diversi campi anche lontani dall’informatica. Solo il sistema di raggruppamento dei dati lo distingue dai suoi predecessori, mantenendo comunque un postulato tipico della programmazione dei flussi informatici: la non modificabilità a seguito di una qualsiasi trasformazione (l’invarianza in matematica).
Il tempo nuova dimensione
Con la Sa, un’informazione inviata può essere simultaneamente conservata. La Sa permette che si possano raccogliere i dati, riprenderli e inviarli, inoltre l’approccio della Sa risponde benissimo alle richieste dell’analisi funzionale soprattutto per la scomposizione delle funzioni e mettendo in giusta evidenza i flussi. Non manca niente alla Sa per essere una metodologia completa, se non la gestione del parametro tempo. Nello stesso anno, il 1977, arriva il metodo Sadt (Structured analysis and design technique) creato da D.T. Ross. Con il Sadt, per la prima volta, si hanno gli strumenti per gestire il tempo grazie al modello di gestione del flusso delle attività di processo. Il metodo si presenta come un mix tra una struttura funzionale (gestione dei dati) e una dinamica. Il mix di modelli di gestione dei dati e delle attività permette di avere dati trasformati dalle azioni e azioni risultanti dai dati. Qualche anno più tardi, nel 1985, è la volta di Sart (Structure analysis real time) l’eredità del Sa. Basta l’estensione "Rt" per permettere alla Software engineering di conquistare il mercato della progettazione industriale. Rimanendo in un contesto funzionale, i processi e i flussi possono essere finalmente generati dinamicamente. I metodi anteriori al 1975 mostrano i loro limiti su tre punti essenziali. In primo luogo, essi generano una forte ridondanza delle informazioni. In seconda battuta, partendo dal punto precendente, l’evidenza dei dati è differenziata. E si giunge rapidamente a una incoerenza del sistema se l’informazione non è ovunque messa in evidenza simultaneamente. All’epoca della crisi del software engineering, tra gli anni 70 e 80, queste incertezze conducono le softwarehouse a considerare all’interno del prezzo finale i costi delle modifiche successive. Queste difficoltà sull’ubiquità dei dati, che devono essere disponibili contemporaneamente e su diverse funzioni, conducono alla loro centralizzazione, portando dei nuovi problemi concettuali. In effetti, i dati non figurano che una sola volta nel database, e non sono condivisi dalle applicazioni e dunque dagli utilizzatori. Il problema è dunque: come costruire un database che sia indipendente dalle applicazioni attuali o future? Come definire le procedure di utilizzo appropriate? I metodi di analisi per funzione non vanno bene a causa di queste difficoltà di gestione dei dati. Inoltre devono essere gli utenti i primi fruitori di un buon sistema informatico. Si deve dunque concepire il database secondo un modello nuovo. È così che metodi antichi come Corig, precursore del Cgi (Common gateway interface), considerato come il primo metodo di analisi e programmazione strutturata inventato da Robert Mallet nel 1974, e qualche modello teorico (le relazioni di Codd, quelle di Chen o le reti di Petri) porteranno alla nascita di Merise (Methode d’etude et de realisation informatique pour les systemes d’enteprise), metodologia in voga, soprattutto in Francia, negli anni 80. Concepita tra gli anni 1977 e 1979, il metodo è frutto dell’opera collettiva di Tardieu, Nancy, Heckenroth, e più tardi anche di Tabourier. La metodologia è pronta alla fine degli anni 80, periodo in cui uno studio dell’ufficio Young stima che il 50% delle aziende utilizzano un metodo di Se, cifra in verità esagerata, e che il 60% tra queste adottano il metodo Merise.
I metodi collaborativi
Il ciclo di studio, validazione e formalizzazione di un progetto è alla base della metodologia Merise. Il primo, lo studio, l’analisi del problema, è ancora molto utilizzato nonostante gli effetti a cui si può andare incontro successivamente, ma il metodo va molto più lontano. Più lontano certamente ma, a suo tempo, limitato dal postulato che oggi sembra superato e rischioso: un progetto informatico è un lavoro a catena di cui si possono prevedere i risultati e le proprietà esclusivamente informatiche. I progetti di oggi sono collaborativi e si evolvono perché l’informazione è condivisa e distribuita. Le applicazioni devono essere indipendenti ma interagibili e le architetture decentralizzate. Gli utenti diventano i principali revisori dei progetti. I linguaggi sono alla base e i metodi possono diventare ricorsivi. È la rivoluzione della programmazione a oggetti. Dopo la fine dei grandi progetti in cui l’informatica ha pensato più a spendere, ora i progetti provengono spesso dalla reingegnerizzazione del software o dalla programmazione tradizionale. Storicamente la genesi dei metodi oggettivi passa innanzitutto dal linguaggio. L’istituto di ricerca norvegese Simula nel 1967 introduce la nozione di classe. Il sistema Smalltalk pone le basi dell’oggetto ereditabile. Nel 1970 il gruppo di Software engineering Ada arriva quasi a costruire una metodologia. In ogni caso realizza un utile strumento di base. Da qui si arriva, alla fine degli anni 80, al concetto di Ooa (Object oriented analysis) e, successivamente, Gary Booch propone Ood (Object oriented design).
Arrivano i consensi
Nello stesso periodo appaiono una pletora di metodi a oggetti di cui il più celebre è l’Omt (Object modelling technique), concepito da James Rumbaugh, che si impone a metà degli anni 80. Dove siamo dunque oggi a più di trent’anni dalla conferenza Nato di Garmich-Partenkirchen? Il Software engeneering non è mai stato tanto nel cuore dell’industria del software. Non soltanto raccoglie i frutti dell’esperienza di questi trent’anni, ma finalmente i consensi in termini di standard riconosciuti. È così che Uml (Unified modelling language) fornisce ai metodi un paradigma comune e, in molti casi, rimpiazza le vecchie metodologie. Riconosciuta dall’Object management group, l’Uml è un metodo riconosciuto quasi a unanimità. A questo punto la battaglia si svolge su due fronti, da una parte i metodi, dall’altra gli strumenti. Se Merise ha funzionato come metodo in ingegneria civile, la programmazione a oggetti si applica ai metodi tipici della produzione industriale. Oggi il Software engineering non segue più delle leggi fisiche che rendono prevedibili i suoi funzionamenti e la maniera in cui è realizzato ma è dinamico, evolutivo.
