Storia dell'informatica - uniud 2009- 10 - corrado bonfanti - traccia lez. 11- 12 ARGOMENTI (EVOLUZIONE DEL SOFTWARE: ALCUNI PERCORSI) SOFTWARE: DI COSA

storia dell'informatica - uniud 2009-10 - corrado bonfanti - traccia lez. 11-12

ARGOMENTI (EVOLUZIONE DEL SOFTWARE: ALCUNI PERCORSI)

SOFTWARE: DI COSA PARLIAMO?

PERIODO PIONIERISTICO: LINGUAGGIO MACCHINA = STRUTTURA HARDWARE

LINGUAGGI DI PROGRAMMAZIONELINGUAGGI DI PROGRAMMAZIONE

INGEGNERIA E INDUSTRIA DEL SW

APPENDICE: ESEMPI FORTRAN E COBOL


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 (AssemblerAssembler).

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 l’apprendimento e l’uso ottimale del linguaggio.

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

FACILITÀ D’USO FACILITÀ D’USO

++

MACHINE INDEPENDENCEMACHINE INDEPENDENCE


FACILITÀ D’USO: FACILITÀ D’USO: comprensibilità, concisione, aderenza al tipo di problemi

Due brevi esempi della programmazione in Fortran e in Cobol (vedi Appendice) illustrano

questi aspetti in maniera intuitiva.


MACHINE INDEPENDENCE: MACHINE INDEPENDENCE: il flusso elaborativoil flusso elaborativo

PROGRAMMA PROGRAMMA SORGENTESORGENTE

(linguaggio di alto livello)

PROGRAMMA

TRADUTTORE AA

(compilatore o interprete)

PROGRAMMA OGGETTO

ESEGUIBILE SULLA

MACCHINA AA

PROGRAMMA

TRADUTTORE BB


PROGRAMMA OGGETTO

ESEGUIBILE SULLA

MACCHINA BB

PROGRAMMA

TRADUTTORE NN


PROGRAMMA OGGETTO

ESEGUIBILE SULLA

MACCHINA NN


MACHINE INDEPENDENCE: MACHINE INDEPENDENCE: il punto di vista del programmatoreil punto di vista del programmatore

PROGRAMMA PROGRAMMA SORGENTESORGENTE

(linguaggio di alto livello)

MACCHINA MACCHINA ASTRATTAASTRATTA

(grammatica del linguaggio)


Il passo successivo ai linguaggi simbolici tipo Assembler 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 astratta 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:

FORTRANFORTRAN - Formula Translator (1955),

COBOLCOBOL - Common Business Oriented Language (1959),

LISPLISP - List Processor (1959),

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

Del linguaggio ALGOLALGOL ci occuperemo più avanti.


Il FortranFortran 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 CobolCobol 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.


Avendo menzionato Grace Murray Hopper, citiamo quasi a mo’ di aneddoto l’origine del termine bug (insetto) e derivati (p. e. debugging) usato nel senso di “errore informatico difficile da individuare”: un insetto sul contatto di un relè interruppe il funzionamento di un calcolatore elettromeccanico che stava eseguendo una serie di calcoli matematici.

Il reperto storico, incollato con un pezzo di scotch, è conservato nel quaderno di lavoro tenuto dalla Hopper, alla data del 9/9 (1945), mentre lavorava sul Mark I del laboratorio di Harvard diretto da Howard Aiken. Malgrado abbia tratto origine da un problema di hardware, è con riferimento al software che oggi si parla correntemente di bug.

La Encyclopedia of Computer Science, alla voce Bug, c’informa che la parola in questione era già stata usata, col significato di malfunzionamento, in una lettera di Thomas Alva Edison datata 1878.


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

Il LispLisp 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 LispCommon Lisp.


Al Dartmouth College, nel 1965, John Kemeny e Thomas Kurz inventarono il BasicBasic come strumento per iniziare gli studenti all’arte della programmazione nell’ambiente Time SharingTime 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; il loro numero attuale è di oltre 2.500.

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).


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


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] Dopo due anni di lavoro, la prima versione dell’Algol fu messa a punto nel corso di un convegno svoltosi 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 americani ed europei (tra questi ricordiamo almeno i nomi del danese Peter Naur, dell’olandese Edsger W. Dijkstra e dello svizzero Niklaus wirth); 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 questione dell’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 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.


CENNO AI NUOVI PARADIGMICENNO AI NUOVI PARADIGMI

Linguaggi “strutturati” (p.e. “goto-less” languages), che incorporano o rendono agevole l’applicazione delle norme della programmazione strutturata. Capostipite: Pascal, Niklaus Wirth, 1971).

Linguaggi non procedurali “orientati agli oggetti” (object oriented). Esempi tipici di uso attuale: C++ (1980), Java (1995). Capostipite: Smalltalk, 1971.

Tecnologia delle “interfacce grafiche” (GUI: Grapical User Intrfaces). L’origine è nelle ricerche condotte allo Xerox PARC (Palo Alto Research Center) nel decennio 1970 e portate al successo commerciale con la esplosiva diffusione dei personal computer (Apple, IBM, Microsoft). Chi volesse approfondire questo argomento può consultare sul web l’articolo [11] in bibliografia.

Applicativi specializzati “user friendly”: editori di testi (text editors / word processors); fogli elettronici (spreadsheets), il cui capostipite è stato VisiCalc (Robert Frankston e Daniel Bricklin, 1979); disegno, dal semplice Power Point ai sofisticati software CAD (Computer Aided Design).

Videogiochi; Navigazione sul Web; … .





LINGUAGGI DI PROGRAMMAZIONE

INGEGNERIA E INDUSTRIA DEL SWINGEGNERIA E INDUSTRIA DEL SW

APPENDICE: ESEMPI FORTRAN E COBOL


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 softwarecrisi del software.


La crisi del software appariva ancor più grave quando si andava a distinguere il costo per lo svilupposviluppo di nuovo software dal costo per la manutenzionemanutenzione 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): Ciclo di vita del software (CVS): il paradigma rudimentale.

PROGETTAZIONE (analista)

SVILUPPO (programmatore)

MANUTENZIONE (anal. e/o progr.)

ESERCIZIO (operatore)


CVS:CVS: modello di Freeman (1978); suddivisione in fasi specialistiche.


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 semplice “a gradini” aveva il grave difetto di focalizzare il controllo di qualità esclusivamente 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.


??

CVS:CVS: insufficienza della validazione “a fine percorso”.


CVS:CVS: 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

CVS:CVS: manutenzione come riciclo nel cvs.

produzione


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 di manutenzione.

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:CVS: il costo degli errori.


Programmazione strutturataProgrammazione strutturata Grafi di controllo di un programma ben strutturato (A) e di uno non strutturato (B).

Una situazione degenere di tipo B può determinarsi fin dall’inizio oppure insorgere per successivi interventi incontrollati su un software di tipo A.

Teorema di G. Jacopini - C. Böhm (1966); E. Dijkstra “Goto statement considered harmful” (1968).

AA BB


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 softwareIndustria del software nel decennio 1980: un business che cresce di oltre il 20% all’anno.

% % %


1983-89

%


Europa Occ. Tasso annuo

medio di crescita 1983-89

%

%%

%

%


Industria del softwareIndustria del software nel decennio 1980: il Packaged Software alla conquista del mercato.


Industria del softwareIndustria del software nel decennio 1980: SAP non è ancora alle viste.



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

Industria del softwareIndustria del software nel decennio 1980: Un panorama variegato: dalle numerosissime microimprese alle grandi aziende con migliaia di dipendenti.



Fonte: [10] nella bibliografia di questa lezione

L’irresistibile ascesa di MicrosoftL’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.). Si veda in particolare la Appendix VI: Key High-Level Languages.

[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.

[11] S.Hénin, M.Zaninelli: “Topi, finestre, icone e tendine: le radici dell’interfaccia grafica”; Mondo Digitale, N.27, sett. 2008, pp.48-57. ( http://www.aicanet.it )





LINGUAGGI DI PROGRAMMAZIONE

INGEGNERIA E INDUSTRIA DEL SW

APPENDICE: ESEMPI FORTRAN E COBOLAPPENDICE: ESEMPI FORTRAN E COBOL


Brevi esempi di programmazione in Fortran e Cobol

Si esemplifica la ricerca sequenziale in una stringa ordinata: dato il numero di matricola di un dipendente (3 cifre decimali), si desidera conoscere il numero del reparto (4 cifre decimali) in cui egli lavora.

I numeri di matricola sono registrati in un “vettore”, i cui 200 elementi sono individuati dal nome del vettore seguito dall’indice in parentesi. Gli elementi del vettore sono ordinati secondo la sequenza ascendente (ma non necessariamente consecutiva) del valore in essi contenuto.

I 200 elementi di un secondo vettore contengono il numero di reparto che, a parità di indice, corrisponde al numero di matricola nel primo vettore.


Esempio CobolEsempio Cobol* LE RIGHE CHE INIZIANO CON ‘*’ SONO COMMENTI, IGNORATI DAL COMPILATORE * … OMISSIS (ALCUNE ISTRUZIONI DICHIARATIVE) … DATA DIVISION. *… OMISSIS (ALCUNE ISTRUZIONI DICHIARATIVE) … WORKING-STORAGE SECTION. 01 VETTORE-MATRICOLE. 02 NUM-MATRICOLA OCCURS 200 TIMES PICTURE IS 9(3). 01 VETTORE-REPARTI.

02 REPARTO OCCURS 200 TIMES PICTURE IS 9(4). 01 INDICE PICTURE IS 9(3). 01 MATRICOLA-DA-TROVARE PICTURE IS 9(3). PROCEDURE DIVISION. * … OMISSIS (ISTRUZIONI PER LA LETTURA DA FILE E REGISTRAZIONE IN MEMORIA * DEL CONTENUTO DEI VETTORI E DELLA “MATRICOLA-DA-TROVARE”) … RICERCA. MOVE 0 TO INDICE. PROSSIMO-ELEMENTO. ADD 1 TO INDICE. IF MATRICOLA-DA-TROVARE = NUM-MATRICOLA (INDICE) GO TO TROVATO. IF MATRICOLA-DA-TROVARE < NUM-MATRICOLA (INDICE) OR INDICE = 200 GO TO NON-TROVATO. GO TO PROSSIMO-ELEMENTO. TROVATO. DISPLAY “IL DIPENDENTE CON MATRICOLA ” MATRICOLA-DA-TROVARE “LAVORA NEL REPARTO “ REPARTO (INDICE) STOP RUN. NON-TROVATO. DISPLAY “IL NUMERO DI MATRICOLA ” MATRICOLA-DA-TROVARE “ NON ESISTE“ STOP RUN. * IL VERBO ‘DISPLAY’, QUI USATO PER EVITARE COMPLICAZIONI INESSENZIALI, * NON SCRIVE SU FILE BENSI DIRETTAMENTE SUL DISPOSITIVO DI CONTROLLO * DEL SISTEMA (TELESCRIVENTE O MONITOR)


C LE RIGHE CHE INIZIANO CON “C” SONO COMMENTI, IGNORATI DAL COMPILATORE DIMENSION NMAT(200), NREP(200)

C … OMISSIS (ISTRUZIONI PER LA LETTURA DA FILE E REGISTRAZIONE IN MEMORIA C DEL CONTENUTO DEI VETTORI E DELLA VARIABILE “MATX” (VEDI APPRESSO) … IND = 0 C LE VARIABILI SEMPLICI (NON DIMENSIONATE) QUALI “IND” E “MATX” SONO C RECEPITE DAL COMPILATORE ALLA LORO PRIMA OCCORRENZA NEL CODICE C SORGENTE 10 IND = IND+1

IF MATX = NMAT(IND) GO TO 20 IF MATX < NMAT(IND) OR IND = 200 GO TO 30

GO TO 10 20 WRITE (1,100) MATX,NREP(IND)

STOP 30 WRITE (1,150) MATX STOP C NELLA NOTAZIONE “WRITE (X,Y)” LA “X” DESIGNA L’UNITA DI OUTPUT (IN QUESTO C CASO: 1 = STAMPANTE) E “Y” INDICA L’ETICHETTA DEL RELATIVO “FORMAT” C (ISTRUZIONE NON ESECUTIVA) 100 FORMAT (‘IL DIPENDENTE CON MATRICOLA ‘,I3,’ LAVORA NEL REPARTO ‘,I4) 150 FORMAT (‘IL NUMERO DI MATRICOLA ‘,I3,’ NON ESISTE’) END C L’ISTRUZIONE “STOP” COMANDA L’ARRESTO DELL’ESECUZIONE IN FASE DI RUN. C L’ISTRUZIONE “END” (NON ESECUTIVA) SEGNALA INVECE AL COMPILATORE IL C TERMINE DEL CODICE SORGENTE

Esempio FortranEsempio Fortran

Documents

Storia dell'informatica - uniud 2009- 10 - corrado bonfanti - traccia lez. 11- 12 ARGOMENTI (EVOLUZIONE DEL SOFTWARE: ALCUNI PERCORSI) SOFTWARE: DI COSA