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