TRACCIA PER LE LEZIONI 10-11 lunedì 9 giugno, ore 14 30 -16 15 , aula I ARGOMENTI

storia dell'informatica - UNIUD 2007-8 - c. bonfanti - traccia lez. 10-11

TRACCIA PER LE LEZIONI 10-11lunedì 9 giugno, ore 1430-1615, aula I

ARGOMENTI

EVOLUZIONE DEL SOFTWARE: ALCUNI PERCORSI


SOFTWARE:

DI COSA PARLIAMO?


Nella letteratura di carattere storico, solo una minoranza di lavori si occupano in profondità dell’evoluzione del software nei suoi molteplici aspetti; in particolare quasi tutte le “storie generali” la trascurano del tutto o la liquidano con cenni fugaci. [1] Solo i

linguaggi di programmazione possono vantare un buon numero di opere specialistiche. [2]

La natura immateriale del software rende poi problematica, se non impossibile, la sua esibizione nelle istituzioni museali che sono invece ormai numerose e ricche di reperti di interesse storico che documentano l’evoluzione dell’hardware.

Un autorevole richiamo verso una maggiore attenzione alla storia del software è stato lanciato in un recente convegno intitolato “History of Computing: Software Issues”.[3] In tale convegno …

[1] Una notevole eccezione è il recente saggio di Paul E. Ceruzzi, tradotto anche in italiano (n.[5] nella bobliografia), che vi dedica l’intero Capitolo 3 - “Gli albori del software, 1952-1968” - e altri ampi passaggi.

[2] Tra queste, i nn.[2], [3] e [4] nella bibliografia.

[3] Gli atti del convegno sono rubricati al n.[6] della bibliografia.


… si è proposto di adottare come criterio storiografico l’osservazione del “fenomeno software” secondo i seguenti punti di vista:



- il software “come arte” (periodo pionieristico),




- il software “come scienza logico-linguistica” (teoria; linguaggi; sistemi operativi),





- il software “come attività economica” (professioni; industria del sw),





- il software “come attività economica” (professioni; industria del sw),

- il software “come tecnica ingegneristica” (ingegneria del sw).


Il termine “software” è un neologismo entrato in voga intorno al 1960 come contrapposto a “hardware”, parola in uso già da tempo[1]; si dava così una connotazione riconoscibile ed emblematica - una “dignità” insomma - a quella che potremmo chiamare “l’altra faccia dell’informatica”.

Inizialmente per “software” s’intendevano i programmi, di qualsiasi genere, necessari a rendere operante un computer. Questa accezione ristretta venne gradualmente estesa fino ad abbracciare tutto il ventaglio di metodologie e di attività associate alla semplice scrittura dei programmi.

Il quadro è diventato estremamente complesso; vediamo di chiarire ……

[1] Il termine “hardware”, come inteso nel gergo informatico, è invece un traslato della parola inglese che corrisponde all’italiano “ferramenta”.


SOFTWARE: IL “NOCCIOLO DURO”

LINGUAGGI DI PROGRAMMAZIONE

SISTEMI OPERATIVI

PROTOCOLLI TLC


SOFTWARE: A QUALE SCOPO?


SISTEMI OPERATIVI

PROTOCOLLI TLC

APPLICAZIONI

“ORIZZONTALI” (D’INTERESSE

GENERALE)

“VERTICALI” (D’INTERESSE

SETTORIALE)

UTENZA / MERCATO


SOFTWARE: COME FARLO?


SISTEMI OPERATIVI

PROTOCOLLI TLC

TOOLS DI SVILUPPO

INGEGNERIA DEL SOFTWARE

APPLICAZIONI


GENERALE)


SETTORIALE)


SOFTWARE: CHI LO FA?


SISTEMI OPERATIVI

PROTOCOLLI TLC

TOOLS DI SVILUPPO


APPLICAZIONI


GENERALE)


SETTORIALE)

UTENZA / MERCATO

SOFTWARE “FREE”

INDUSTRIA DEL SOFTWARE

AUTOPRODUZIONE


SOFTWARE: ENTRO QUALI CONTESTI?

ARCHITETTURE HARDWARE (PROCESSORI,

FIRMWARE, PERIFERICHE, RETI)


SISTEMI OPERATIVI

PROTOCOLLI TLC

TOOLS DI SVILUPPO


INFORMATICA TEORICA (COMPUTER SCIENCE)

STANDARD “DI FATTO” / “ LEGALI”


SOFTWARE: UN POSSIBILE QUADRO DI RIFERIMENTO

Ogni casella e ogni relazione dovrebbe avere una sua storia! Noi seguiremo solo alcuni percorsi.


SISTEMI OPERATIVI

PROTOCOLLI TLC

TOOLS DI SVILUPPO


STANDARD “DI FATTO” / “ LEGALI”

ARCHITETTURE HARDWARE (PROCESSORI,

FIRMWARE, PERIFERICHE, RETI)

INFORMATICA TEORICA (COMPUTER SCIENCE)

APPLICAZIONI


GENERALE)


SETTORIALE)

UTENZA / MERCATO

SOFTWARE “FREE”

INDUSTRIA DEL SOFTWARE

AUTOPRODUZIONE


PERIODO PIONIERISTICO:

LINGUAGGIO MACCHINA = = STRUTTURA HARDWARE


Il programma “inaugurale” (1948) preparato per il test della Baby Machine dell’Università di Manchester (vedi una precedente lezione).

Il programma effettivo, scritto bit per bit in linguaggio macchina e introdotto in memoria mediante una serie di switches, si trova nelle due colonne sulla destra.

Fonte: [8] nella bibliografia di questa lezione


Appunti autografi di A.M.Turing: programmazione del computer Mark I (Manchester, 1953)



Appunti autografi di A.M.Turing: programmazione del computer Mark I (Manchester, 1953)

A caccia di un errore:

How did this happen ?

Fonte: [8] nella bibliografia di questa lezione (con adattamenti del docente)




Nei computer pionieristici della prima generazione, compresi quelli prodotti in ambiente industriale, il software era praticamente inesistente e quindi il suo sviluppo rimaneva completamente a carico di ogni utilizzatore.

Il gruppo inglese diretto da Maurice Wilkes, lavorando sul loro EDSAC (1949) all’Università di Cambridge, fu tra i primi ad affrontare in maniera sistematica anche il problema “primigenio” del software mettendo a punto e dando alle stampe una libreria di componenti software (sottoprogrammi o subroutines) per risolvere una volta per tutte i problemi che più di frequente ricorrono nel calcolo matematico.

Abbiamo detto “una volta per tutte”, ma bisogna intendersi: i sottoprogrammi della libreria EDSAC, pur utilissimi come esemplificazione di un approccio sistematico, non erano infatti applicabili a nessun computer diverso da esso. Fatto che era esplicitamente avvertito nel sottotitolo del libro: With special reference to the EDSAC.

Il software EDSAC si basava su due elementi chiave destinati a fare scuola in quanto preludevano a fondamentali componenti del cosiddetto “software di base”.

Il primo era il programma di caricamento che leggeva il simbolico da nastro, lo traslitterava in codice binario di macchina e trasferiva il controllo a tale codice eseguibile. Questo ingegnoso ed elegante programma, di appena 40 istruzioni designate come initial orders, svolgeva quindi le funzioni di traduttore e di loader.

I programmi non potevano essere “salvati” in codice di macchina e quindi ogni loro esecuzione doveva ripartire dal nastro simbolico; in questo senso il processo di traduzione può essere considerato affine alla tecnica degli intrpretatori piuttosto che a quella dei compilatori.

Il secondo era il meccanismo di chiamata dei sottoprogrammi e di ritorno al programma chiamante: una invenzione di David Wheeler passata alla storia come Wheeler’s Jump.

Considerata l’importanza storica dell’EDSAC e il suo valore paradigmatico nei confronti di molti computer dell’epoca, nel seguito vi farò riferimento a titolo esemplificativo.


Sruttura generale dell’EDSAC (1949), rappresentativa dei computer pionieristici.

Input e output sono ancora rudimentali: - lettore/perforatore di banda di carta - telescrivente.

Notare inoltre l’esiguità degli organi aritmetici (no Floating Point): - registro moltiplicatore - accumulatore (addizioni e sottrazioni).

Ne conseguono le caratteristiche salienti del corredo di istruzioni native ovvero del linguaggio macchina, unico linguaggio inizialmente disponibile per costruire il software.


MULTIPLIER REGISTER

ACCUMULATOR


Il corredo di istruzioni native (Order Code) dell’EDSAC. Fonte: [1] nella bibliografia di questa lezione (con adattamenti del docente)


Nella rappresentazione simbolica delle istruzioni il primo carattere (lettera maiuscola) costituisce il codice operativo e il secondo (n, quando presente) designa l’indirizzo dell’operando (o argomento) su cui agisce l’istruzione stessa.

Per brevità sorvoliamo sul significato della seconda lettera maiuscola, quando presente.


Unica struttura di controllo: il salto condizionato


Registro accumulatore: un passaggio obbligato


Si tratta quindi di istruzioni a un solo indirizzo, che aderiscono strettamente alla struttura fisica della macchina.

Questo implica l’intervento di un organo non dichiarato nel corpo dell’istruzione ma individuato univocamente dalla descrizione (“semantica”) dell’istruzione stessa.

Nel caso dell’EDSAC, come in quasi tutti i computer coevi, tale organo poteva essere l’accumulatore (vedi p.e. l’istruzione A n) oppure il registro moltiplicatore (come nell’istruzione H n).

I prospetti che seguono illustrano alcune caratteristiche del linguaggio macchina dei computer pionieristici; si nota quante poche siano state le eccezioni rispetto al formato a un solo indirizzo.


PERCORSI DA MEMORIA A MEMORIA NELLE ARCHITETTURE TIPO EDSAC CON ISTRUZIONI NATIVE A UN SOLO INDIRIZZO:

I REGISTRI ARITMETICI (IN PARTICOLARE L’ACCUMULATORE) COSTITUIVANO UN PASSAGGIO OBBLIGATO.

MULTIPLIER REGISTER

ACCUMULATOR



codice operativo

argomento (indirizzo di memoria)

Il secondo argomento (tipicamente un organo aritmetico come l’accumulatore o il moltiplicatore) è implicito e lo si evince dalla semantica dell’istruzione specificata dal codice operativo.

Formato delle istruzioni a un solo indirizzo


codice operativo

argomento (indirizzo di memoria)

Il secondo argomento (tipicamente un organo aritmetico come l’accumulatore o il moltiplicatore) è implicito e lo si evince dalla semantica dell’istruzione specificata dal codice operativo.

Esempio 1 (codice EDSAC): copiare il contenuto della posizione di memoria n1 nella posizione di memoria n2

Formato delle istruzioni a un solo indirizzo

T n2

A n1

Tranfer the contents of the accumulator to storage location

n2 and clear the accumulator. (N.B.: serve solo per azzerare l’accumulatore; dato lo scopo finale dell’esempio, il precedente contento dell’accumulatore è irrilevante)

Add the number in storage location n1 into the accumulator.

T n2


n2 and clear the accumulator. (N.B.: nel caso non si volesse lasciare azzerato l’accumulatore, andrebbe usata

l’istruzione U n2)


Esempio 2 (codice EDSAC): sommare i contenuti delle posizioni di memoria n1 e n2 e mettere il risultato nella posizione di memoria n2

T n3

A n1


n3 and clear the accumulator. (N.B.: serve solo per

azzerare l’accumulatore; la posizione di memoria n3 è usata come area “di comodo”)

Add the number in storage location n1 into the accumulator.

T n2


n2 and clear the accumulator. (N.B.: nel caso non si volesse lasciare azzerato l’accumulatore, andrebbe usata

l’istruzione U n2)

A n2 Add the number in storage location n2 into the accumulator.


I due esempi precedenti, per quanto banali, mostrano quanto la programmazione in linguaggio macchina fosse complicata e prona ad errori.

La semplice struttura dell’EDSAC, e il conseguente formato a un solo indirizzo delle istruzioni, è stata peraltro adottata da quasi tutti i progettisti dei computer pionieristici, come evidenziato nelle due tavole che seguono.



1948 1949 1950 1952 1953 1953


Nel formato a 3 indirizzi, il quarto elemento dell’istruzione (indicato da “+1”) contiene l’indirizzo della prossima istruzione da eseguire; indirizzo che, di norma, è invece contenuto in un apposito registro denominato Instruction Counter.



Nei primi computers, il corredo delle istruzioni di macchina (istruzioni “native”) raramente ne prevedeva più di una ventina.



Copy n1 n2

T n2

A n1

T n2

Livello utente

MICROPROGRAMMA su ROMLivello firmware

Livello hardware

LINGUAGGIO MACCHINA

COMANDI ESEGUIBILI


Nel computer EDSAC II (1951) Maurice Wilkes introdusse il concetto di macchina microprogrammata.

Il microprogramma era una ROM che contieneva un programma interprete capace di tradurre in comandi effettivamente eseguibili a livello hardware (e inaccessibili al programmatore) le istruzioni scritte in un linguaggio più sintetico e più potente: era questo il linguaggio disponibile al programmatore, al quale appariva come il vero linguagggio macchina (o linguaggio “nativo”). Con riferimento all’Esempio 1, la slide illustra come il microprogramma potrebbe ad esempio sovrapporsi a una modesta struttura hardware tipo EDSAC (primo modello) per trasformarla, agli occhi dell’utente, in una più potente macchina con istruzioni a 2 indirizzi (la generalizzazione a 3 indirizzi è intuitiva).

La microprogrammazione fu una delle idee più innovative e di maggior successo nella storia dell’informatica moderna e dette luogo alla tecnologia cosiddetta firmware che ha avuto e ha tuttora innumerevoli applicazioni. Esempi tipici di macchine microprogrammate sono state le famiglie di computer IBM 360 e 370 e la serie VAX della DEC (Digital Equipment Corporation) nonché, in Italia, la CEP (Calcolatrice Elettronica Pisana) e l’ELEA 6001, dell’Olivetti.

Nel modello a strati, in cui lo strato più esterno è l’interfaccia utente, il firmware è rappresentato come come lo strato più interno che avvolge il nucleo hardware: una sorta di ibrido in cui l’immaterialità del software possiede stabilmente una sede fisica che ne realizza le funzioni.


Questo è l’elenco dei tipi (Category) di sottoprogrammi, quasi un centinaio, approntati per la libreria EDSAC



L’aritmetica floating point era realizzata via software e le subroutines necessarie furono un classico adempimento a carico di ogni team di programmatori, fino a quando i computer non furono dotati degli appositi dispositivi hardware e delle corrispondenti istruzioni native.

EDSAC, per di più, non disponeva neppure di hardware per la divisione; a tale operazione provvedevano quindi le subroutines della categoria D.


Le subroutines per l’input e per l’output formattato (print and layout), nella pratica, erano non meno utili dei sottoprogrammi matematici. Programmare la ricezione di dati dal lettore di nastro perforato o l’invio alla telescrivente, carattere per carattere, erano infatti operazioni particolarmente ostiche.


Le istruzioni, qui incorniciate in colore, venivano digitate sulla telescrivente e perforate su nastro di carta in una forma simbolica che, sebbene ancora piuttosto criptica, segnava un progresso notevole rispetto alla codifica puramente binaria.


Esempio di subroutine della Libreria EDSAC: il caso più semplice di divisione.


I programmi erano perforati su nastro e il corredo di software risiedeva quindi su una collezione di strisce di carta perforata. Sulla sinistra della foto si distinguono i nastri dei programmi da eseguire in giornata (job queue).


Folclore protoinformatico: preparazione dei programmi per

l’EDSAC.



La foto ritrae un’operatrice intenta alla telescrivente “fuori linea” (cioè non collegata al computer né a una linea telefonica) dotata di un lettore e di un perforatore di banda di carta.

Le istruzioni del programma, scritte sul modulo nel leggìo, vengono digitate sulla tastiera e registrate sul nastro perforato. I sottoprogrammi vengono invece letti dal nastro di libreria e, al punto opportuno, riprodotti automaticamente sul nastro principale. L’intera libreria dei sottoprogrammi è custodita nella cassettiera sulla sinistra.

L’input e l’output al/dal computer erano effettuati rispettivamente per mezzo di un lettore di nastro di carta e di una telescrivente collegati direttamente alla macchina.

Queste modalità operative continuarono a far parte del folclore protoinformatico anche quando i lettori veloci di schede, mutuati dalla meccanografia, divennero il mezzo di input preferito; alle strisce di carta si sostituirono allora i “pacchi” (deck) di schede.


LINGUAGGI DI

PROGRAMMAZIONE


Lo sviluppo dei linguaggi di programmazione è stato motivato da diverse istanze la prima delle quali, facilmente intuibile, è stata quella di rendere meno ostico il lavoro di programmazione.

La risposta iniziale a tale requisito è stata l’introduzione dei linguaggi cosiddetti assemblativi (Assembler).

N. B. Con il termine “assemblatore” (assembler) si designano sia il linguaggio e sia il programma traduttore.


Brano di un programma scritto in assembler (IBM 360)

op. codelabel operands / arguments comments


Pur mantenendo una corrispondenza uno a uno con le istruzioni del linguaggio macchina, un linguaggio di tipo assembler presenta i seguenti principali vantaggi:

- il codice operativo (op.code) è tendenzialmente mnemonico (p.e. MVI = MoVe Immediate; BC = Branch on Condition; LA = Load Address);

- l’etichetta (= indirizzo) o label dell’istruzione e degli operandi (campi di dati) può essere espressa con nomi di comodo scelti dal programmatore;

- i campi di dati vengono definiti mediante le pseudo-istruzioni che, nell’esempio, compaiono nelle ultime tre righe (DS = Define Storage; DC = Define Constant, con indicazione del valore iniziale);

- i commenti esplicativi sono ad uso del programmatore e vengono ignorati dal programma traduttore.

Un gran numero di linguaggi di questo tipo, più o meno sofisticati, furono sviluppati autonomamente da gruppi di programmatori per uso “locale” sul computer che avevano in dotazione. Quelli di cui è rimasta memoria sono tuttavia legati ai computer che avevano la maggiore diffusione e quindi, inevitabilmente, ai vari modelli IBM: tra i più precoci - metà degli anni ‘50 - il SOAP (Symbolic Optimizer and Assembly Program) per l’IBM 650.

Gli assembler rimanevano comunque linguaggi di una notevole complessità - comportavano anche la necessità di imparare a conoscere con un notevole grado di dettaglio il funzionamento interno del computer su cui si lavorava - e per di più lasciavano irrisolto un aspetto critico: tutto il software sviluppato per una certa macchina risultava inutilizzabile su macchine differenti, anche se possedute da una stessa organizzazione, o quando si passava a macchine più evolute.

Per di più, se da un lato il progresso delle tecnologie hardware offriva al programmatore in assembler un corredo di istruzioni native sempre più ampio e versatile, dall’altro lato - e quasi paradossalmente - l’eccessiva proliferazione di opzioni gli veniva a complicare la vita.

Le figure che seguono, anche senza commento, possono dare un’idea dei livelli di complessità raggiunti (a titolo esemplificativo, il riferimento è alla famiglia di elaboratori IBM 360, messa sul mercato nel 1964).


Alcune delle 130 istruzioni disponibili nel linguaggio assembler per l’IBM 360 (1964)


Formati delle istruzioni del sistema IBM 360.


4 4 Digit

Sign

4 4 Sign

Digit

0000 001011010100

parola

mezza parola

byte

0100 0011 0100 1101 0010 0000 0000 0000

come sopra ma su una parola

come sopra ma su due parole

0000 0001 0010 0011 0100 1100

00011111 1111 1111 11000010 0011 0100

Sei modi per rappresentare uno stesso numero: +1234 (sistema IBM 360)


Nel corso degli anni Sessanta, solo la Control Data Corporation era andata in controtendenza con il CDC 6600 che - pur appartenendo alla classe dei supercomputer - era basato su un instruction set piccolo e semplice.

Nel 1975, il problema fu affrontato e avviato a soluzione da un gruppo di ricerca dei laboratori IBM diretto da John Cocke. Ne scaturì la cosiddetta architettura RISC (Reduced Instruction Set Computer) che prevedeva un numero limitato di istruzioni native di formato unico ed assai veloci (eseguibili in un solo ciclo di macchina), assistito da un gran numero di registri. Per certi versi - altro paradosso! - era un ritorno alle semplici strutture che avevano caratterizzato i computer pionieristici. L’acronimo RISC fu proposto da David Patterson (Università di Berkeley); lui e John Hennessy (Università di Stanford) approfondirono le ricerche iniziate dalla IBM e l’architettura RISC riscosse l’adesione di numerosi costruttori.

Per sottolineare la rottura rispetto alla precedente tendenza, le architetture tradizionali vennero poi designate come CISC (Complex Instruction Set Computer).


L’invenzione dei cosiddetti linguaggi “di alto livello” o “problem oriented” va inquadrata nella prospettiva

machine independence + facilità d’uso


Il passo successivo fu quindi inteso a conferire ai linguaggi di programmazione un drastico miglioramento in termini di comprensibilità, di facilità di apprendimento e di predisposizione verso una specifica classe di problemi.

A tale istanza se ne aggiunse però un’altra, nuova e del tutto inattesa: la tendenza all’ indipendenza dalla macchina (machine independence), nel senso in cui si parla anche di portabilità del software.

Alla lunga, è stata proprio l’indipendenza dalla macchina a determinare un salto di qualità nella cultura informatica: l’invenzione dei linguaggi di alto livello.

Si è trattato di una vera e propria rivoluzione copernicana dopo la quale l’interlocutore dell’agente umano non è stata più una specifica macchina fisica, bensì una macchina virtuale stabilmente definita dalla grammatica, dalla sintassi e dalla semantica del linguaggio di alto livello.

Il software scritto in un determinato linguaggio di alto livello poteva infatti “girare” su computer di qualsiasi tipo, purché dotati di uno specifico programma traduttore - compilatore o interprete che fosse - scritto una volta per tutte per quel tipo di computer.


Esempi celebri, dei quali daremo brevi cenni, sono:

FORTRAN - Formula Translator (1955),

COBOL - Common Business Oriented Language (1959),

LISP - List Processor (1959),

BASIC - Beginner’s All-purpose Symbolic Instruction Code (1965).

Del linguaggio ALGOL ci occuperemo più avanti.


Il Fortran si distingue per la predisposizione al calcolo scientifico in quanto la sua grammatica si ispira alle espressioni tipiche dell’algebra; utilizza inoltre un insieme di parole “riservate” tratte dalla lingua inglese (p.e. if, do, integer, read, write, goto).

Il Fortran fu definito in casa IBM da un gruppo di ricerca diretto da John Backus[1] e il primo programma compilatore (Fortran I) vide la luce nel 1955.

Grazie alla sua efficacia e alla forza di trascinamento dell’IBM, divenne uno standard “di fatto” e tutti i concorrenti, volenti o nolenti, svilupparono compilatori Fortran per i propri computer. [1] In parte ispirato da un compilatore che Laning e Zierler avevano realizzato per Whirlwind.


E’ verosimile che, nelle intenzioni iniziali dell’IBM, lo sviluppo del Fortran avesse come obiettivo quello di acquisire un vantaggio competitivo nei confronti della concorrenza e non già quello dell’indipendenza dalla macchina.

Tale intento fu in effetti conseguito per un breve periodo ma, considerato l’enorme gradimento che anche i clienti non-IBM manifestavano verso il Fortran, le aziende concorrenti si attrezzarono rapidamente per costruire i compilatori per i propri computer.

Del resto le specifiche del linguaggio erano di dominio pubblico - non foss’altro perché erano contenute nei manuali di addestramento - e, partendo da esse, la cosa non era poi così difficile per i concorrenti.

Una tattica di questo genere, nel caso del Fortran ma anche nella storia di altri linguaggi, funzionò ancor meglio allorché tali linguaggi, nati come standard di fatto all’interno di qualche azienda o istituzione, divennero standard legali ad opera degli enti di standardizzazione riconosciuti a livello internazionale.


Il linguaggio Cobol fu invece definito nel 1959 da un organismo collegiale denominato CODASYL (Committee on Data Systems Languages) costituito su iniziativa del Ministero della Difesa (DOD: Department of Defense) con la partecipazione di esperti accademici e dei più importanti costruttori di computer.

Uno dei principali protagonisti nella definizione del Cobol è stata Grace Murray Hopper, famosa anche per essere stata la prima donna a raggiungere il grado di contrammiraglio nella US Navy.[1]

[1] Anche il Cobol aveva un antecedente: il Flow-Matic che, non a caso, era stato sviluppato dalla UNIVAC (divisione della Remington-Rand) sotto la direzione di Hopper.


Il DOD era di gran lunga il più grande e influente utilizzatore di sistemi informatici, con centinaia di centri di elaborazione dotati di computer delle svariate marche; il suo deciso intervento in favore della definizione di un linguaggio “comune” derivava dalla confusione organizzativa e dall’enorme spreco di risorse profuse nella produzione di software per la gestione delle procedure amministrative (“business”).

Ogni centro sviluppava infatti propri sistemi di software per risolvere i medesimi problemi, utilizzando linguaggi i più disparati, tra loro incompatibili e non “portabili”,da quelli tipo assembler a quelli più evoluti ma ancora rudimentali e inventati localmente.

Da allora in avanti tutti i fornitori che volessero fare affari con gli enti governativi USA - e si trattava spesso di affari enormi - dovettero garantire la disponibilità di un compilatore Cobol per lo sviluppo di software gestionale. L’esempio del DOD fece scuola presso la generalità degli utilizzatori di computer anche se la programmazione nei vari assembler, considerata più efficiente, rimase in voga per lungo tempo.

La drastica presa di posizione del DOD intendeva reagire ai primi sintomi della cosiddetta “crisi del software” di cui parlerò più avanti.


La genesi degli altri due linguaggi prima menzionati, Lisp e Basic, è invece avvenuta nell’ambiente accademico.

Il Lisp fu concepito da John McCarthy e Marvin Minsky nell’ambito dell’Artificial Intelligence Project del MIT (1959) e si affermò come strumento di elezione per le ricerche sull’intelligenza artificiale. Ne derivarono una quantità di varianti e di dialetti sviluppati negli Stati Uniti entro un intreccio di interessi industriali, di ricerca accademica e di finanziamenti pubblici, sostenuti specialmente dall’ARPA (Advanced Research Project Agency) che, nel 1981, tentò senza successo di pervenire a uno standard. Solo in seguito fu definito lo standard ANSI Common Lisp.


Al Dartmouth College, nel 1965, John Kemeny e Thomas Kurz inventarono il Basic come strumento per iniziare gli studenti all’arte della programmazione nell’ambiente Time Sharing di cui disponeva il college; il traduttore di tipo interprete lo rendeva specialmente adatto a questo uso. Questa stessa caratteristica si rivelò più tardi appropriata anche alle capacità dei primi microprocessori; il Basic fornito alla Apple da Bill Gates, non senza qualche astuzia affaristica da parte di questo intraprendente giovanotto, segnò il primo business di rilievo nella travolgente storia della Microsoft.


Si è visto come i linguaggi di programmazione di maggiore successo siano nati come standard “di fatto”.

Tuttavia, anche a causa della loro rilevanza sotto il profilo economico, essi si sono ben presto imposti all’attenzione degli organismi di standardizzazione riconosciuti a livello internazionale.

Con le opportune revisioni critiche, tali organismi hanno conferito lo status di standard “legali” ai linguaggi di programmazione di maggiore interesse; solo allora il requisito della machine independence è stato conseguito nella sua interezza.


LINGUAGGIO Standard ANSI Standard ISO

FORTRAN (1955) 1966 1972

COBOL (1959) 1968 1972

LISP (1959) 1994 1997

BASIC (1965) 1987 1991

Cronologia della prima definizione degli standard ANSI (American National Standards Institute) e ISO (International Organization for Standardization)

Da notare che gli standard sono successivamente sottoposti a revisioni periodiche.


La proliferazione dei linguaggi di programmazione è tutt’altro che cessata.

E questo trend - anche se in molti casi giustificato da oggettive necessità di specializzazione - ha dato luogo alla metafora della “torre di Babele” che fu proposta dall’autorevole periodico Communications of the ACM (Association for Computing Machinery).




I linguaggi assemblativi non hanno richiesto alcuno speciale accorgimento per la loro formulazione in quanto, nella sostanza, si limitavano a sovrapporre una nomenclatura simbolica al preesistente linguaggio macchina di cui ricalcavano la struttura.

La situazione cambiò radicalmente con l’avvento dei linguaggi di alto livello che sono delle vere e proprie lingue artificiali autonome.[1] Dopo i primi tentativi di sapore artigianale, ci si rese conto che la definizione di questi linguaggi artificiali trovava un supporto quanto mai appropriato nei risultati che, giusto in quel periodo, stavano emergendo dalle ricerche degli studiosi di linguistica e di logica matematica.

Risultarono di speciale rilevanza e pertinenza le ricerche di Noam Chomsky sulla struttura delle grammatiche generative e trasformazionali applicate ai linguaggi liberi dal contesto, nei quali ogni termine ha un’interpretazione univoca, a prescindere dal contesto entro il quale è formulato.[2]

[1] Il problema a cui mi riferisco è quello della definizione formale di un linguaggio; problema ben distinto da quello dell’implementazione di un programma traduttore (compilatore o interprete che sia).

[2] La relativa facilità con cui si poteva realizzare la traduzione tra due linguaggi artificiali (tali sono infatti, seppure di natura diversa, i linguaggi di alto livello e i linguaggi macchina) suscitò ottimistiche previsioni sulla possibilità di pervenire rapidamente alla traduzione automatica anche tra lingue “naturali”. Previsioni che andarono deluse tanto che questo problema rimane a tutt’oggi aperto alle ricerche in intelligenza artificiale; la causa principale consiste proprio nella dipendenza semantica che i termini del linguaggio naturale manifestano nei confronti del contesto sia testuale che situazionale. Basta pensare alle metafore, ai doppi sensi, all’evoluzione delle accezioni correnti, agli omonimi se non addirittura alla mimica e alla gestualità. Risultati soddisfacenti si sono conseguiti solo nella traduzione e nel sunteggio della letteratura scientifica grazie al fatto che la prosa scientifica è di norma poco fantasiosa e tendenzialmente non ambigua e, per di più, fa largo uso di quel particolare linguaggio universale che è la notazione matematica.


Tale connubio interdisciplinare[3], che già aveva influenzato la definizione e l’affinamento del Fortran e del Cobol, fu espressamente adottato come metodo di riferimento allorché si costituì un gruppo indipendente, di estrazione prevalentemente accademica, allo scopo di definire un linguaggio di alto livello, denominato Algol - Algorithmic Language, adatto ad ogni circostanza applicativa.[4] La prima versione dell’Algol fu messa a punto nel corso di una riunione svoltasi a Zurigo nel 1958; una nova versione fu definita da un comitato riunitosi a Parigi nel 1960 e fu pubblicata due anni dopo, con minori aggiustamenti. [5]

[3] Nel quale confluivano altri strumenti teorici e metodologici quali le funzioni ricorsive, gli automi a stati finiti, la teoria dei grafi etc.

[4] In tema di linguaggi algoritmici è necessario menzionare due notevoli precedenti: il Plankalkül (Piano di calcolo) proposto da Konrad Zuse nel lontano 1945 e il linguaggio che Corrado Böhm aveva definito nella sua tesi di dottorato al Politecnico Federale di Zurigo (tesi del 1952, pubblicata in Italia nel 1954). La comunità di lavoro dell’Algol vedeva una partecipazione paritetica di studiosi europei e americani; un fatto inusuale, visto che nell’Europa continentale si era ancora fermi alla concezione di computer scientifici costruiti in esemplare unico mentre americani e inglesi erano ormai assuefatti all’impiego di macchine prodotte industrialmente per un ampio mercato. Riuscire a conciliare i due punti di vista fu una bella manifestazione di reciproca buona volontà anche se, in questo come in altri casi, non mancarono dispute su questioni sostanziali e anche su argomenti apparentemente minori; tra queste ultime va ricordata la disputa per l’adozione del punto decimale (uso anglosassone) piuttosto che della virgola (uso dell’Europa continentale) il cui esito di compromesso fu quello di introdurre nel Cobol la clausola opzionale “decimal point is comma”.

[5] Entrambe le riunioni, precedute da intensi lavori preparatori, si protrassero per otto giorni. Con evidente riferimento agli eventi, il rapporto finale sulla prima versione fu chiamato Algol 58 o Zürich Report e la seconda versione Algol 60. Il successivo Algol 68 risultò un linguaggio notevolmente diverso dal genitore e fu specificato da un gruppo di lavoro formalmente costituito all’interno di un organismo sovranazionale e indipendente: IFIP - Internatinoal Federation for Information Processing.


Nessuna delle versioni dell’Algol divenne popolare come linguaggio di programmazione; in parte a causa della sua concezione marcatamente teorica e lontana dalla sensibilità comune del popolo dei programmatori e in parte a causa dalla freddezza con cui fu accolto dai maggiori costruttori di computer, specialmente quelli americani, che ormai avevano puntato quasi tutte le carte su Fortran e Cobol il cui successo di pubblico non accennava a declinare. [6]

In compenso, l’Algol influì profondamente sull’ambiente scientifico, tanto che la branca specialistica dell’informatica teorica prese corpo e identità ad opera soprattutto di quanti avevano contribuito alla sua definizione. [7]

Tra i numerosi risultati delle ricerche connesse al progetto Algol ricordiamo i metalinguaggi per la specifica dei linguaggi di programmazione (in particolre: BNF - Backus Naur Form[8]; VDL - Vienna Definition Language) e le Reti di Petri per il trattamento

dei processi con precedenze. [9]

[6] Vanno tenuti in conto anche gli analoghi insuccessi in cui incappò perfino la grande IBM con lo sviluppo di due nuovi linguaggi di alto livello: l’APL (A Programming Language) e il PL/ I (Programming Language I). APL derivava da una notazione formale che Howard Aiken - famoso pioniere dei computer nella Harvard University - aveva concepito nel 1955 come strumento didattico. Ripreso dieci anni dopo da Kenneth Iverson e trasformato in un potente linguaggio per il calcolo numerico, risultava tuttavia di uso altamente specialistico e inoltre prevedeva un set di caratteri esotici che comportava l’uso di tastiere speciali.

Il PL/ I, al contrario, era pensato come linguaggio general purpose; fu proposto nel 1965 per enfatizzare la carica di innovazione che accompagnava l’uscita del Sistema /360 ma si scontrò anch’esso con l’inerzia con cui Fortran e Cobol si opponevano al cambiamento.

Anche la Olivetti incappò in un problema analogo: come linguaggio standard per l’ELEA 6001 (1961) era stato scelto il Palgo, sviluppato da Mauro Pacelli e collaboratori in analogia con l’Algol. La “Associazione Utenti 6001”, composta in massima parte da ricercatori universitari, reclamò invece un compilatore Fortran che fu messo a punto in gran fretta da un team diretto da Marisa Bellisario.

[7] Tra di essi il già ricordato Corrado Böhm.

[8] L’acronimo BNF fu inizialmente letto come Backus Normal Form ma poi apparve opportuno riconoscere il contributo paritetico del danese Peter Naur.

[9] Carl A. Petri era ricercatore e docente nell’Università di Berlino; le Reti di Petri furono usate, tra l’altro, per la gestione delle risorse all’interno di un Sistema Operativo.


INGEGNERIA E

INDUSTRIA DEL SW


Nel decennio 1950 comparvero i primi elementi del software “di base” o “di sistema” (p.e. Linkers e Loaders, Sort-Merge, Compilatori, IOCS - Input/Output Control System), embrioni dei complessi Sistemi Operativi che raggiunsero prestazioni soddisfacenti solo con la metà del decennio 1960.

La complessità di questi sistemi crebbe di pari passo con l’insorgere di nuove problematiche quali la sovrapposizione (overlapping) tra elaborazione e operazioni di I/O, i segnali di Interrupt, la protezione della memoria, la multiprogrammazione, il time Sharing, l’elaborazione in tempo reale, il calcolo parallelo, le basi di dati relazionali, i sistemi distribuiti, Le interfacce grafiche e via elencando. Tuttavia in questa lezione non intendo esplorare il percorso evolutivo dei sistemi operativi.

Riguardo al software applicativo, col tempo presero piede le “librerie” fornite dai costruttori di hardware oppure rese disponibili dagli utenti (contributed programs) nell’ambito delle loro comunità organizzate, senza peraltro riuscire a intaccare la sostanziale “autarchia software” di ciascun utente.

Ed è stato proprio il software applicativo ad emergere, nel corso del decennio 1960, come problema cruciale per l’universo degli utilizzatori di sistemi informatici: era la cosiddetta crisi del software (Software Crisis).


La “Curva di (Barry) Boehm”.

All’inizio degli anni ‘70 essa fece il giro del mondo dando evidenza e popolarità al fenomeno della crisi del software.


La crisi del software appariva ancor più grave quando si andava a distinguere il costo per lo sviluppo di nuovo software dal costo per la manutenzione di quello già esistente


I grafici erano basati su dati empirici, non sempre tra loro omogenei e relativi a un campione ristretto.

Fornivano tuttavia una rappresentazione del trend sostanzialmente attendibile.


La produzione di software evolveva dalla scrittura di singoli programmi verso la costruzione di sistemi software sempre più complessi e sofisticati. Divenne quindi a tutti chiaro come la produzione di nuovo software, e ancor di più la manutenzione dell’esistente, fosse caratterizzata da costi crescenti derivanti dall’elevato contenuto di lavoro umano insito in tutte le fasi del ciclo di vita (CVS) di un sistema software.

E’ stata questa l’ottica in cui hanno preso avvio le varie branche dell’ingegneria del software, intese sia a migliorare la qualità dei prodotti e sia a razionalizzare e a rendere meno costoso il processo produttivo.

Però, a dispetto dei progressi di questa moderna disciplina, entrambi gli obiettivi sono stati raggiunti solo parzialmente, in stridente contrasto con le tecnologie hardware, in particolare la microelettronica, che hanno generato prodotti caratterizzati da prestazioni sempre più spinte (vedi la “legge di Moore”) e da prezzi unitari rapidamente decrescenti.

Il paradigma del ciclo di vita del software, allorché si cominciò a parlarne, veniva semplicisticamente ridotto alla sequenza “progettazione-sviluppo-manutenzione”.


Ciclo di vita del software (CVS): paradigma rudimentale.

PROGETTAZIONE (analista)

SVILUPPO (programmatore)

MANUTENZIONE (anal. e/o progr.)

ESERCIZIO


CVS: modello di Freeman (1978)


Successivi modelli più articolati, come quello di Freeman, comportarono importanti conseguenze organizzative e metodologiche e definirono le principali linee di sviluppo per l’ingegneria del software nei suoi aspetti teorici e applicativi; clamorosi fallimenti o mezzi disastri in alcuni gradi progetti software stavano a testimoniare la necessità di un approccio sistemico e tendenzialmente quantitativo.

Tra l’altro fu chiarito che ciascuna fase del ciclo di vita

- richiedeva degli skill specialistici che rendevano obsoleta la classificazione professionale che, fino ad allora, si era cristallizzata attorno alle figure tradizionali dell’analista e del programmatore;

- comportava metodologie e metriche specifiche per la previsione/controllo dei requisiti di costo e di qualità. [1]

L’ingegneria del software incorporava peraltro una serie di regole empiriche alcune delle quali, col senno di poi, possono apparire ovvie e banali ma che fino ad allora erano state ignorate o disattese. [2]

Il modello “a gradini” focalizzava peraltro il controllo di qualità sul test finale del software realizzato (verifica e correzione).

[1] Quanto alle metriche, va ricordato che per lungo tempo si dette fiducia all’unità di misura più soggettiva e aleatoria che si possa immaginare: la linea di codice (codice sorgente, beninteso). Su questo piede d’argilla si costruivano poi modelli di valutazione e di previsione della produttività (p.e. “linee di codice / mese uomo”) che pretendevano di essere credibili, con tutte le conseguenze del caso.

[2] Basti un esempio. Era prassi normale che l’autore di qualcosa (p.e. di un programma software) fosse anche responsabile del test di questo qualcosa. L’approccio razionale bollava invece tale prassi come inefficace e dannosa dal momento che l’efficacia del test si misura dal numero di errori scoperti e non dal “tutto va bene” con cui l’autore dell’oggetto testato tenderebbe inevitabilmente ad autogratificarsi.



validazione “passo a passo”


I canoni dell’ingegneria del software vennero invece a chiarire che il controllo di qualità va distribuito “passo a passo” lungo l’intero CVS e consiste nel verificare, prima di procedere oltre, che il prodotto di ciascuna fase sia conforme e congruente a quanto specificato nella fase precedente.


}A B C D E

Manutenzione come riciclo nel CVS


Inoltre, la manutenzione del software non venne più concepita come un processo accessorio e separato bensì come un riciclo sul CVS, a partire di volta in volta dalla fase corrispondente ai motivi che hanno determinato l’intervento manutentivo.

Gli interventi immediati sul software (manutenzione “correttiva”) corrispondono ai percorsi del tipo D o E mentre i ben più impegnativi interventi dovuti a nuove o diverse esigenze dell’utente (manutenzione “evolutiva”) o all’opportunità di sfruttare nuove tecnologie (manutenzione “adeguativa”) comportano dei ricicli a partire dalle fasi alte del CVS (percorsi A o B).


CVS: il costo degli errori.


Si è già visto come l’igegneria del software abbia sviluppato tecniche e metodologie specifiche ognuna delle fasi del CVS. Particolare attenzione si è dedicata alla fase di effettiva scrittura del software (codifica), che rimane comunque la più “pesante” in termini di impiego di risorse umane; in tale campo hanno avuto enorme importanza e notevole successo le metodologie di programmazione strutturata; il loro fondamento teorico è stato stabilito dal celebre teorema dimostrato da Corrado Böhm e Giuseppe jacopini nel loro articolo Flow diagrams, Turing machines and languages with only two formation rules (1966) poi reso popolare da E. Dijkstra con l’articolo Goto statement considered harmful (1968) che ebbe vasta risonanza.

Alla fine del 1968, a seguito di un procedimento antitrust verso la IBM, fu resa obbligatoria la vendita separata (unbundling) dei prodotti software che prima venivano forniti gratuitamente, o per meglio dire “compresi nel prezzo”, dai costruttori di hardware. Questo aprì finalmente le porte alla nascita e poi alla crescita vigorosa di una vera e propria industria indipendente: l’ industria del software, qualificata come “industria” a dispetto della immaterialità dei suoi prodotti.

La produzione industriale di software, fin dall’inizio, si è articolata in due filoni distinti e ben caratterizzati:

- quello dei sistemi dedicati (custom software o software personalizzato) sviluppati su commessa di un cliente singolo avente necessità specifiche (grosse aziende di servizio (banche, assicurazioni, trasporti, …) e manifatturiere, enti pubblici centrali e locali);

- quello del software preconfezionato (packaged software) che risolve invece problemi ricorrenti presso una vasta categoria di utilizzatori. Problemi che possono essere di interesse generale (p.e. Sistemi Operativi, Software matematico, CAD, Spreadsheet, Videoscrittura ...) oppure squisitamente applicativi (p.e. Contabilità, Magazzino, Servizi demografici …). Nel primo caso si parla di prodotti, e mercati, “orizzontali”; nel secondo caso di “verticali”.

Da notare che molte aziende qualificabili, almeno al loro esordio, come produttori di software abbinano sempre più intensamente alla loro attività l’offerta di servizi ICT (outsourcing, consulenza, formazione, servizi in rete…)

Lindustria del software in Italia decolla nel 1969, subito dopo l’unbundling americano; tra le prime aziende a entrare in questo nuovo settore di attività segnalo la Syntax del Gruppo Olivetti e l’Italsiel, nata in seno all’IRI e poi rapidamente cresciuta trasformandosi nel Gruppo Finsiel.

I prospetti che seguono illustrano per sommi capi la struttura e il trend dell’industria del software a partire dal decennio 1980.


% % %


Industria del software: un business che cresce di oltre il 20% all’anno.

1983-89

%


Europa Occ. Tasso annuo

medio di crescita 1983-89

%

%%

%

%


Anni Ottanta: il Packaged Software alla conquista del mercato.





Un panorama variegato: dalle numerosissime microimprese alle grandi aziende con migliaia di dipendenti.

Fatturato medio per singola impresa

72,5

1,1

5,52,20,90,3

28%

100%

15%12%26%19%

0,4%

100%

3%6%

32%58%

In complesso



L’irresistibile ascesa di Microsoft


Bibliografia

[1] M.V.Wilkes, D.J.Wheeler, S.Gill: The preparation of programs for an electronic digital computer; Addison Wesley, 1951.

[2] J.A.Sammet: Programming Languages: History and Fundamentals; Prentice-Hall, 1969.

[3] R.L..Wexelblatt (Editor): History of Programming Languages; Academic Press, 1981.

[4] T.J.Bergin, R.G.Gibson (Editors): History of Programming Languages - II; ACM Press and Addison-Wesley, 1996.

[5] P.E.Ceruzzi: Storia dell’informatica; Apogeo, 2006.

[6] U.Hashagen, R.Keil-Slawik, A.Norberg (Editors): History of Computing: Softwre Issues; Springer, 2002.

[7] A.Ralston, E.D.Reilly, D.Hemmendinger (Editors): Encyclopedia of Computer Science; John Wiley & Sons, 2003 (4th ed.).

[8] S.Lavington: Early Brtish Computers; Digital Press, 1980.

[9] A.Alberigi Quaranta, M. Paoli: “L’industria italiana del software nel contesto europeo: struttura e tendenze evolutive.”; L’INDUSTRIA, n.4, 1986, pp.645-674.

[10] A.D.Chandler: La rivoluzione elettronica; Egea - Università Bocconi Editore, 2003.

Documents

TRACCIA PER LE LEZIONI 10-11 lunedì 9 giugno, ore 14 30 -16 15 , aula I ARGOMENTI