Sistema sull' Opera completa

Scrivania di lavoro di Alberto Acquaro



Novita'   12 giugno 2004


     Il testo seguente rappresenta la TERZA delle Dispense del "Corso PER RICERCATORI" neo-laureati, di qualsiasi disciplina. La prima sua edizione si terrà in Firenze, appena si sarà raggiunto il numero di 15 aspiranti frequentatori. La prima edizione di questo Corso, configurato in incontri settimanali, per la durata di 6 mesi, sarà a titolo gratuito. La data d'inizio del corso, il giorno della settimana e l'orario saranno fissati in un incontro preliminare, nel quale sarà anche illustrato il programma di massima e saranno accettate le iscrizioni dei frequentatori, il che non comporterà per loro alcun impegno, se non quello morale di far sì che il corso risulti fruttuoso (nella pratica, essi non dovranno apporre alcuna firma).

      Si prega di segnalare la propria volontà di partecipare all'incontro preliminare, indicando i dati necessari (cognome, nome, tipo di laurea, recapito), il giorno e l'ora preferiti per tale incontro. Lo scrivente, autore delle dispense, propone la scelta: "sabato, ore 15", ma terrà conto delle indicazioni in tal senso, da inviare al seguente recapito:

Acquaro Alberto - via Claudio Monteverdi, 82 - 50144 Firenze
tel.: +39 055/ 094.62.97 - E-mail : acquaro@dante2000.it

      Il testo della Dispensa potrà essere "scaricato" gratuitamente, con un Clic sull'apposito comando a fine pagina.

___________________________________________________________________________________


AGLI ASPIRANTI RICERCATORI    -    DISPENSA 3


SCIENZA DELLE INFORMAZIONI ED ELABORAZIONE ELETTRONICA Firenze 8 giugno 2004


     La Scienza delle Informazioni gioca nella nostra epoca un ruolo centrale, determinante nella rivoluzione culturale che stiamo vivendo. Come già detto, essa ha oggi la funzione di catalizzare il necessario “processo di fusione delle discipline”, di coordinarle e di far convergere tutti gli sforzi ad un medesimo scopo comune, l’incremento del grado di conoscenza del nostro mondo.

     Certamente non per gli addetti ai lavori, occorre subito mettere in chiaro le differenze tra Scienza delle Informazioni (Informatica) ed Elaborazione Automatica dei Dati (EAD), visto che spesso le loro specifiche attribuzioni non risultano, ai più, chiare e che vengono facilmente confuse. L’uomo ha sempre utilizzato e costantemente incrementato un complesso di regole per il trattamento delle informazioni; oggi il complesso di tali regole si è esteso e specializzato in misura da dar luogo ad una “disciplina”, cioè ad un complesso formalizzato di principi e di conseguenti leggi. In altri termini, l’Informatica non è altro che la nuova denominazione di un’attività umana antica quanto l’uomo stesso. L’ EAD costituisce un’applicazione dell’Informatica mediante gli strumenti offerti dall’attuale tecnologia. Tra l’Informatica e l’EAD esiste un rapporto analogo a quello esistente tra la “Fisica di base” ed una qualunque delle Fisiche applicate, con la differenza che l’EAD tratta un genere di applicazioni assolutamente indispensabili perché l’Informatica possa assolvere le sue funzioni.
Il motivo dell’insistenza nel mettere l’accento sulle differenze tra le due attività sta nel fatto che spesso, ai non addetti ai lavori, capita di pensare che tanti problemi possano essere risolti con la semplice adozione di un elaboratore e di persone che ne conoscano il funzionamento; è come avere una penna senza lo scrittore.

     Esistono alcuni concetti che la Scienza delle Informazioni ha assunto direttamente dalla Fisica di base; uno di questi è quello di “Entropia” ed è il caso di spendere su di esso qualche parola. In Fisica capita di studiare sistemi costituiti da un insieme innumerevole di particelle piccolissime (si pensi, ad esempio, ad un gas); in tali condizioni, costretti a rinunziare a studiarli a livello microscopico, li consideriamo a livello macroscopico, osservando il comportamento medio delle particelle, il che comporta il ricorso agli strumenti della Statistica e quindi l'introduzione del concetto di probabilità. Questo particolare tipo di approccio segna una branca della Fisica, la “Termodinamica”, che comporta la definizione di una serie di grandezze fisiche (misurabili), come il “calore”, la “temperatura”, la “pressione” ed altre, fra le quali, l’ “Entropia”. Tutta la Termodinamica si fonda su tre principi, dai quali possono desumersi molte conseguenze. Ebbene, al nostro discorso serve una conseguenza immediata del secondo principio della Termodinamica, che può essere così espressa:
             “L’Entropia di un sistema termodinamico ISOLATO tende sempre a CRESCERE”.
Consistendo l’evoluzione del sistema in trasferimenti di energia tra le sue parti ed essendo, questi, possibili solamente tra punti a differenti temperature, un sistema che ha raggiunto la sua massima Entropia non evolve più, è morto. Allora l’enunciato precedente può essere formulato anche così:
                       “Un sistema termodinamico ISOLATO è destinato alla quiete eterna”.
Ciò significa che la condizione necessaria per mantenere in vita un sistema è che gli venga fornita energia dall’esterno.

     Il fuggevole ricorso al mondo della Fisica era, quantomeno, utile, in quando il discorso fatto per i sistemi termodinamici può essere ripetuto, in maniera identica, per i sistemi informativi, ove si sostituisca al termine “energia” il termine “intelligenza” (magari, sotto forma di software). L’analogia è talmente calzante, che il termine “Entropia” è stato adottato anche dalla Scienza delle Informazioni.
Quanto appena detto ci richiama alla mente, non a caso, il discorso fatto, nella Dispensa 1, a proposito del superamento dell’antitesi Creazionismo-Evoluzionismo. Proprio lì si diceva della vita, o meglio, del progresso del nostro mondo ottenuto mediante un susseguirsi di continui atti creativi dall’esterno, che tengono conto dell’adattamento degli esseri viventi al loro ambiente. Tali continui “aggiustamenti” (mutazioni) consistono nella scrittura di nuovo software (apporto di nuova intelligenza) nei nostri DNA.
Questo disegno, semplice, elegante per la sua coerenza interna e conforme alle nostre conoscenze sperimentali, possiamo vederlo solamente grazie al nuovo punto di osservazione offertoci dalla rivoluzione culturale in atto.



SU ALCUNI TERMINI DELLA ELABORAZIONE AUTOMATICA                      Firenze 9 giugno 2004


     Avendo tutti noi acquisito una qualche, anche minima, familiarità con gli elaboratori elettronici, cercheremo di evitare quanto possa essere desunto anche da un modesto dizionario specialistico, soffermandoci solamente su qualche termine che dia lo spunto per chiarire alcuni concetti, che sappiamo non essere bagaglio della maggioranza.

     E’ d’obbligo dire subito due parole sui termini “hardware” e “software”, che, notoriamente, indicano i due componenti essenziali di un elaboratore elettronico. Il primo si riferisce alla sua parte materiale, il secondo a quella immateriale. Se pensiamo a noi stessi come a degli elaboratori (immensamente più complessi e potenti, rispetto a quelli che realizziamo noi), l’hardware sarebbe costituito dal nostro corpo e il software dall’anima.
“Software” è, a nostro avviso, uno dei pochi termini in lingua inglese che ci conviene importare, in quanto il contrasto del “soft” con l’ “hard” rende in qualche modo l’idea di immaterialità; si tratta di strutture logiche, che esistono a prescindere dal loro eventuale supporto materiale. Un software inizia ad esistere nella nostra mente; siamo costretti a registrarlo su un supporto, solamente se vogliamo trasferirlo all’esterno, comunicarlo. A tal proposito, ci piace quanto, in genere, si dice di una persona, alludendo al tempo anteriore alla sua nascita: “Quando era nella mente di Dio”.
A causa della sua immaterialità, in un elaboratore, il software non è fisicamente distinguibile dall’ hardware; è intelligenza che dà forma alla materia e la finalizza; insieme, danno luogo a un’opera. Si pensi al David di Michelangelo e, sicuramente, si avrà più chiara la differenza tra hardware e software, e, forse, si capirà anche come mai gli Italiani risultano naturalmente molto portati alla produzione del software.
La corrente traduzione in Italiano del termine (“programmi”) non ci piace affatto, in quanto la troviamo fortemente riduttiva rispetto al concetto da esprimere.

     Abbiamo avuto un esempio di come, termini nati con l’ EAD, abbiano una valenza che va ben oltre questo settore applicativo, appartengono all’Informatica. Un altro esempio di tal tipo è costituito dalla locuzione “risposta in tempo reale” (real time). Abbiamo il sospetto che, in un sondaggio sul suo significato, la risposta più frequente sarebbe: “risposta immediata”, mentre la risposta esatta dovrebbe essere: “risposta in tempo utile”. Per chiarire, converrà portare un paio di esempi. Alla richiesta di prenotazione di un posto in un volo del giorno seguente, la risposta, data dopo una o due ore, potrebbe ancora essere considerata in tempo reale. La risposta di un software che calcola, per un radar, la posizione e la velocità di un aereo, avrà un tempo reale molto ristretto, magari solamente di qualche microsecondo, considerando l’enorme mole di calcolo che deve essere eseguita durante un giro del radar stesso. Speriamo che i due esempi abbiano chiarito come il “tempo reale” sia un grandezza da definire, di volta in volta, in dipendenza della particolare funzione e del suo contesto.

     L’importanza decisiva della nascita degli elaboratori elettronici sta nel fatto che i loro tempi di lavoro dipendono dalle possibili velocità di propagazione degli elettroni nei conduttori. Tali velocità sono talmente elevate, che consentono all’elaboratore di fornire risposte in tempo reale, anche quando questo sia estremamente ristretto. Diamo appena un’idea dei possibili tempi di esecuzione di un elaboratore, comunque enormemente più alti rispetto a quelli che si hanno nella nostra biologia: l’intera Commedia di Dante può essere letta da un elaboratore di media potenza in una piccola frazione di secondo; è un esecutore di rapidità eccezionale, ma tanto, tanto stupido, da risultare a volte irritante; legge la Commedia o un nostro scritto con lo stesso interesse, cioè nullo.
E’ invalsa l’usanza di indicare la rapidità di lavoro di una “Memoria centrale” (il cervello di un elaboratore) in Hertz (unità di frequenza, cicli al secondo). Dal punto di vista funzionale, è come se ci fosse un direttore d’orchestra che scandisce il tempo;   ad esempio, in un elaboratore che lavora ad 1 GHz (Giga Hertz), la bacchetta del direttore batte il tempo un miliardo di volte al secondo.
E’ chiaro come solamente una tecnologia che consentisse simili tempi di elaborazione avrebbe potuto concorrere a farci acquisire il nuovo punto di osservazione, caratterizzante la rivoluzione culturale in atto.



SULLA TIPOLOGIA DEL SOFTWARE                                                       Firenze 10 giugno 2004


     La continua evoluzione della elaborazione elettronica ha imposto la formalizzazione di tutto l’insieme delle relative conoscenze in una disciplina, l’ Elaborazione Automatica dei Dati (EAD). In particolare, il software è stato classificato in funzione di alcune sue caratteristiche, fra le quali, la fascia di utenza, il tipo di attività che esso automatizza, il tipo di linguaggio di programmazione usato per la sua scrittura, il tipo di hardware a cui esso è destinato, etc.

     Tentiamo subito di chiarire il significato del termine “software di base”. Volendone dare una definizione esatta, dovremmo dire che un software si dice “di base” se riguarda un’attività o un’utenza abbastanza varia da consentire di individuare nel suo ambito differenti specializzazioni. Portiamo un paio di esempi atti a chiarire il concetto.
Windows XP” è un Sistema Operativo e, come tale, può servire tutti coloro che posseggono un hardware ad esso compatibile; si tratta, allora, di un software di base, in quanto la sua utenza può essere distinta in numerose categorie, che useranno anche altri software, consoni alle rispettive attività. Un Sistema Operativo è un classico esempio di software di base in quanto esegue, per conto di tutti gli altri software operanti nel suo ambiente, tutte quelle funzioni necessarie alla comunicazione dell’elaboratore con l’esterno e alla richiesta diretta all’ hardware delle risorse necessarie. Pensando a quel fantastico elaboratore che è l’uomo, un Sistema Operativo svolge funzioni analoghe a quelle dei nostri organi di senso. Esso deve essere sempre attivo per supportare ogni richiesta di altri software eventualmente mandati in esecuzione.
Un altro esempio significativo di software di base potrebbe essere il “SelDoc” (Selezione Documenti), un sistema di “Information Retrieval” (Ricerca documentaria), realizzato dallo scrivente perché servisse da “base” al sistema applicativo “DANTE 2000”, nel quale sono state inglobate tutte le funzioni del “SelDoc” stesso. Gli “Information Retrieval” sono sistemi per la Documentazione automatica, specializzati nella selezione di documenti per argomenti, e, come tali, possono essere utilizzati per realizzare un grande numero di sistemi applicativi.
Possiamo concludere, proponendo una più semplice definizione di “Software di base”: è un software che possa servire da base al funzionamento di altri software.

     Altra caratteristica di un software da considerare riguarda il grado di complessità delle attività che esso automatizza. Cerchiamo di vederci più chiaro. Ogni azione elementare ordinata dal software, alla fine verrà tradotta dal Sistema Operativo (in gergo, esploderà) in una serie di istruzioni all’ hardware, istruzioni che vengono date nel linguaggio ad esso comprensibile, cioè in “linguaggio-macchina”. Se l’ hardware è di natura “digitale” tale linguaggio nasce da un alfabeto costituito da due soli simboli, 0 e 1, che corrispondono ai due possibili stati di un componente elettronico elementare (spento / acceso). In sostanza, una istruzione data dal nostro software arriva all’ hardware tradotta in una serie lunghissima di zeri e di uno, cioè di “bit” (binary digit). E’ chiaro che più saranno sofisticate le singole operazioni ordinate, più lunghe saranno le corrispondenti serie di bit. Ebbene, un software si dirà “avanzato” (o simbolico) nella misura in cui proporrà all’ hardware operazioni sofisticate, corrispondenti quindi a sequenze di bit di grande lunghezza. Ma, poiché il comunicare con la macchina, nel suo linguaggio, si rivelò subito un compito assurdamente penoso, furono creati dei “metalinguaggi” che ci consentissero di scrivere un software in forma più vicina a quella del linguaggio naturale e, in particolare del linguaggio proprio dell’attività da automatizzare, e quindi meno simile alla forma del linguaggio della macchina. Nacquero, cioè, i “linguaggi di programmazione”, il che ha comportato la produzione degli opportuni software di base (uno, per ogni linguaggio di programmazione) che fornissero le traduzioni in linguaggio-macchina”. Nacquero, così, i “Compilatori”, che forniscono la traduzione in linguaggio-macchina di interi discorsi fatti nel linguaggio di programmazione scelto, traduzione che può essere “data in pasto” all’ elaboratore anche in tempo differito;   si introdussero anche gli “Interpreti”, che consentono un colloquio diretto con la macchina, nel senso che ogni frase viene tradotta e fatta eseguire subito. Ovviamente, si parlerà anche di linguaggi di programmazione più o meno “avanzati” o “simbolici”.



ATTIVITA’ E RUOLI NELLA PRODUZIONE DEL SOFWARE                         Firenze 11 giugno 2004


     Un cenno alle competenze necessarie alla produzione di un software degno di questo nome è assolutamente necessario. Viviamo in un Paese, che dovrebbe essere il leader in questa cruciale attività e che, per la inadeguatezza (considerate le dovute eccezioni) della nostra classe politica e del nostro mondo accademico, è, a tal riguardo, da considerarsi al livello di terzo mondo. Eppure, si tratta di un’attività che sembra fatta su misura per il popolo italiano, che non ha risorse naturali significative, se non quelle derivanti dalla mente, e che è risultato, da un’approfondita ricerca, il secondo al mondo per vocazione naturale a tale tipo di attività. Inseriti nel contesto europeo, che dovrebbe ripararci dal nostro maggior difetto, la mancanza di senso delle istituzioni, gli Italiani, se ben governati, potrebbero fare da traino all’intera Europa, anche considerando il fatto che l’attività di produzione del software non ha bisogno di grandi risorse finanziarie e può produrne in misura inimmaginabile.
Oggi già inizia a valere la seguente relazione: “produzione di software = potere”, che, con il passare degli anni, varrà sempre di più.

     A dare la misura del predetto nostro stato di arretratezza è la convinzione di non pochi, secondo la quale, per realizzare un software bastino dei programmatori, cioè, che sia sufficiente la conoscenza di un linguaggio di programmazione. E’ come se si volesse affidare la costruzione di un ponte o di un palazzo a un muratore. Oggi, per introdurre l’Informatica nelle scuole, si acquista qualche elaboratore e si insegna ai ragazzi ad usare software importati, abilitandoli, così, al nostro attuale ruolo, cioè a quello di buone vacche da latte. Tutto questo è il risultato di decenni e decenni di disinteresse e di incompetenza, a qualunque livello, da parte di quanti sono istituzionalmente responsabili della gestione del mondo della ricerca.

     Vediamo, per sommi capi, quali siano i ruoli necessari nella progettazione e nella realizzazione di un sistema di software. Ipotizziamo che debba essere automatizzato un certo settore operativo che assolva determinate funzioni. Allo scopo, sarà composto un gruppo di lavoro che copra tutte le competenze necessarie.
Va subito posta una condizione necessaria al buon esito dell’impresa: al gruppo non devono partecipare esperti del settore in questione; il loro apporto, ovviamente necessario, deve essere acquisito a livello di consulenza esterna. Tale principio, che, probabilmente non sarà citato in nessun trattato, scaturisce dall’esperienza di automazione, maturata nel corso di decenni. La presenza nel gruppo di un esperto della materia porterebbe inevitabilmente a un software con alto tasso di soggettività, tale da renderlo inadatto a servire adeguatamente la totalità dei possibili utenti. Abbiamo assistito alla fine impietosa di tanti grandi progetti, per i quali erano state impegnate notevoli risorse; si era anche pensato che solamente l’apporto diretto di esperti del settore ne avrebbe garantito il successo. Al contrario, all’interno del gruppo devono essere garantite alcune professionalità, ma solamente di tipo informatico.

     Alla guida del gruppo di lavoro deve esserci un “progettista di software”, la cui professionalità deve essere garantita da: un corso di studi equivalente al corso di laurea in Scienze delle Informazioni, indirizzato alla specifica attività, e un’adeguata esperienza di progettazione, che ne garantisca l’abilitazione alla professione, come avviene per ogni altra attività professionale. Vista l’atipicità e la particolare complessità dell’attività, più che in altri casi, a supporto della preparazione deve esserci una particolare inclinazione naturale, che a noi piace chiamare “sensibilità informatica”, che comporta un insieme di caratteristiche, fra le quali, una grande capacità di astrazione; forse, è proprio questa la qualità che fa eccellere il “buon progettista”.
Il primo compito del progettista è quello di ottenere, in tempi ristretti, nella propria mente, una sorta di radiografia dell’ambiente da automatizzare. Egli arriva a questo attraverso una serie di interviste al personale dell’ambiente stesso. La sua abilità sta nella capacità di distinguere subito, nel grande flusso di informazioni, le strutture funzionali portanti dai dettagli. Il progettista esperto sa che, in genere, coglierà le informazioni più importanti dagli operatori, piuttosto che dal personale dirigente. Egli avvierà la progettazione solamente quando “sentirà” di avere in mente un disegno coerente. A questo punto, tradurrà sulla carta quello che è già nella sua mente, producendo diagrammi a grandi blocchi funzionali, il cui dettaglio sarà, in seguito, descritto in altri diagrammi a blocchi. Sin da questi primi passi, egli dovrà imporre un criterio di

                                    STRUTTURAZIONE STRETTAMENTE FUNZIONALE ,

criterio che dovrà poi essere, in ogni fase, rispettato, sino alla finale scrittura del software.

     Conviene sottolineare l’importanza dell’ultimo concetto espresso, che abbiamo imparato a conoscere direttamente dai nostri progettisti; esso è, infatti, uno schema logico sempre presente in natura, che, se risulta decisivo nella produzione del software, è utilissimo in tutte le altre discipline, in quanto è riferibile a qualunque sistema informativo. In parole semplici, in una struttura operativa complessa noi dobbiamo individuare le diverse funzioni; accrescendo il livello di dettaglio, poi, dobbiamo, in ognuna di esse, individuare le eventuali funzioni componenti, e così via, creando una “struttura”. Ma l’importante è che essa risulti “strettamente” funzionale, cioè che ad ogni funzione corrispondano sue specifiche finalità che la individuano e l’assolvimento di specifici compiti, e SOLAMENTE di quelli. In altri termini, la struttura funzionale deve MINIMIZZARE, per quanto possibile, la RIDONDANZA. La misura del rispetto di tale principio condizionerà pesantemente la vita futura del software progettato. Un sistema ben strutturato, oltre a consentire un impiego ottimale delle risorse, potrà crescere più liberamente e più rapidamente. Ma, il vantaggio più notevole, un software ben strutturato lo offrirà nella fase di normale manutenzione, che è di gran lunga la più costosa. Infatti, gli aggiornamenti, richiesti da inevitabili variazioni delle procedure operative o dalla rilevazione di errori (pochi, se il gruppo ha lavorato bene), risulteranno decisamente più agevoli, in quanto l’individuazione dei moduli di software interessati è immediata. Al contrario, un software non ben strutturato risulterà poco efficiente, costosissimo ed è destinato a morire.

     Nella fase d’impostazione il progettista di software si avvale della consulenza di “sistemisti” per prendere alcune importanti decisioni di fondo, relative al tipo di hardware e ai software di base che dovranno supportare il sistema da progettare. Fra queste, le decisioni più delicate sono quelle che possono garantire una buona “portabilità” del sistema stesso, cioè la sua compatibilità, anche futura, con gli “ambienti” più diffusi.
Visto lo stato del mercato, le possibilità di scelta del Sistema Operativo sono veramente poche, il che rappresenta un ovvio vantaggio, ma anche uno svantaggio: la mancanza di concorrenza, inevitabilmente, abbassa la qualità dell’offerta. Avendo a disposizione più versioni di uno stesso Sistema Operativo, per ottenere la massima portabilità è opportuna la scelta della versione meno avanzata, anche, eventualmente, a costo di dover scrivere, per questo, una maggiore quantità di software.
Relativamente più libera è la scelta del linguaggio di programmazione. Nei limiti delle competenze del gruppo, è ancora consigliabile privilegiare la scelta che garantisca la massima portabilità del sistema. A questo fine, va scelto il linguaggio di maggiore diffusione, anche a costo di rinunziare a un linguaggio più avanzato, che farebbe risparmiare lavoro.

     Una volta prodotti i necessari diagrammi a blocchi funzionali, inizia il lavoro degli “analisti di procedure”, che hanno il compito di produrre, per ogni funzione, diagrammi a blocchi a livello di passi operativi. Il modo di procedere non è univoco; l’analista deve scegliere gli opportuni “algoritmi”, cioè la sequenza di passi operativi che porti ai risultati prefissati. Facciamo un esempio che possa chiarire il compito assegnato all’analista di procedure. Pensiamo alla gestione di una tabella di nominativi, per la quale il progettista, sulla base delle specifiche d’uso, ha indicato opportuni limiti ai relativi tempi di gestione. Ebbene, a fronte della funzione “ricerca di un nominativo” della tabella, l’analista potrebbe operare la scelta del metodo di soluzione (algoritmo) fra tre possibilità:    a.ricerca sequenziale”, nella quale si parte dal primo elemento di tabella e si prosegue, in sequenza, sino al rinvenimento dell’elemento cercato;     b.ricerca binaria o logaritmica”, che presuppone un ordinamento a monte degli elementi (per esempio, secondo l’ordine alfabetico), nella quale la ricerca è analoga a quella che facciamo quando cerchiamo un termine in un dizionario;    c.ricerca Hash”, che, oltre a dare il vantaggio di non dovere ordinare la tabella, garantisce i tempi medi di ricerca migliori. La scelta dell’analista sarà fatta in funzione delle specifiche operative particolari e delle caratteristiche del linguaggio di programmazione scelto a monte.
Dall’esempio fatto si desume che l’analista di procedure deve conoscere un complesso di tecniche, che si acquisiscono nel corso di laurea in Informatica, ed avere alle spalle una buona esperienza di più linguaggi di programmazione. I diagrammi, a livello di dettaglio di passi operativi, prodotti dall’analista costituiscono l’input per i programmatori.

     Il programmatore, che, ovviamente, deve avere un'ottima conoscenza del linguaggio scelto, avrà un compito prettamente esecutivo (Dio ci scampi dai programmatori creativi!); egli deve tradurre i diagrammi dell’analista nel linguaggio di programmazione scelto; l’unica libertà di scelta che egli ha è nell’ambito delle possibilità offerte dal linguaggio stesso. Tale compito è, però, tutt’altro che banale. La qualità di un programmatore si misura dalla sua abilità di tradurre i passi operativi in funzione delle caratteristiche di funzionamento dell’ hardware, allo scopo di ottimizzare i tempi di esecuzione. Un buon programmatore deve avere alle spalle, dopo un adeguato corso d’istruzione sul linguaggio, un’esperienza di almeno un paio d’anni in un buon gruppo di lavoro per la produzione di software. Dopo questa esperienza, egli potrà con facilità passare all’uso di altri linguaggi.
I moduli, una volta tradotti nel linguaggio di programmazione (in gergo, tradotti in codice) devono essere provati in esecuzione, al che penserà l’ “Operatore”.

     Una fase delicatissima è poi quella del “debugging” del software prodotto; occorre “fargli le pulci”, cioè andare alla ricerca dei suoi inevitabili errori, nella maggioranza dei casi, originatisi nella fase di programmazione. Visto che le possibili strade che un software consente di percorrere sono innumerevoli, prove esaustive in tal senso sono impossibili; allora, dopo un serio “debugging” fatto nell’ambito del gruppo, è previsto il “debugging dell’utente”, che segnalerà opportunamente le malfunzioni rilevate.

     Concludiamo la dispensa con un paio di osservazioni. Nella breve esposizione fatta abbiamo delineato, pur in modo sommario, i diversi ruoli necessari nell’attività di produzione del software, ruoli che, in genere, nei gruppi di lavoro per grandi progetti di automazione, corrispondo a persone diverse. Accade che, per progetti di medie proporzioni, alcuni di tali ruoli si assommino in una stessa persona; ad esempio, accade quasi sempre che un programmatore svolga anche la funzione di operatore oppure accade anche che un’analista programmi anche. Tutto ciò può avere scarsa importanza, a patto che si abbiano ben chiari i ruoli da coprire e se ne abbiano le relative competenze.
La seconda, più che una osservazione, è una domanda rivolta al lettore. Siamo riusciti a far cogliere la misura della nostra arretratezza nel settore, quando non sia acquisita opinione comune, che è pura follia l’affidare la produzione di software a programmatori, anche se esperti?


--== o ==--



NOTA : Le parti seguenti delle presenti dispense saranno rese disponibili, sempre gratuitamente, al capitolo "Novità" del sito www.dante2000.it .  
( Alberto Acquaro )


____________________________________________________________________________________



Per poter visualizzare i file di tipo PDF presenti in questo Sito occorre utilizzare l'apposito software Acrobat Reader prodotto dalla Soc. Adobe , concessoci in licenza d'uso e distribuzione, tutti i diritti sono riservati e l'uso di tale prodotto è esclusivamente personale. Potete scaricare ed utilizzare gratuitamente tale software direttamente cliccando sul nome del software o da altre fonti, ed accettando le condizioni di utilizzo proposte dal Produttore.
____________________________________________________________________________________







"DANTE 2000" - Scrivania di lavoro di Alberto Acquaro

Sito a cura di Filarete S.r.l.