| Lei pone una questione assai interessante e
di notevole rilievo. I ragazzi che frequentano gli ultimi anni delle scuole superiori, sanno in qualche modo programmare vuoi
in ragione di un proficuo insegnamento vuoi perché si sono perfezionati da soli. Molti posseggono un computer proprio
e dimostrano una grande agilità specie tra gli iscritti all'ITIS ed all'ITC.
Tuttavia le evidenti qualità manuali spesso si accompagnano ad una carente cultura professionale,
cioè ad un orientamento metodologico approssimatico e talora fuorviante. Se la lacuna non viene
corretta, nel mondo del lavoro si immette una persona che prima
o poi avrà difficoltà personali e creerà problemi agli altri. L'origine di tutti i
mali è l'esclusiva concezione della programmazione come esercizio logico-intellettivo (vedi
risposte 27 e 29). Il
quale resta utile in taluni ambienti ma non dovunque. Dunque oggi
siamo orientati ad una visione diversificata la quale dà ragione dei metodi
di programmazione in contesti diversi.
In particolare qui mettiamo a fuoco alcune
necessità del software applicativo in un contesto aziendale/istituzionale.
Vediamo come alcuni luoghi comuni che derivano da una concezione
logico-astratta della programmazione sono incoerenti con quanto necessita
per il software gestionale. L'astrazione ha un valore ben limitato per chi dovrà sviluppare i
programmi di calcolo commerciale, statistiche attuariali, stampe di paghe e
stipendi.
Idee comuni |
Commenti |
| Il programma è la soluzione di un problema
logico. |
Il programmatore
applicativo non risolve
problemi logici ed invece crea un manufatto tecnologico sulla base di specifiche
tecniche o specifiche di programmazione
che gli dicono esattamente quello
che il programma dovrà fare. Dunque in azienda non si tratta affatto di risolvere problema
astratto ma di seguire indicazioni precise. Quando le specifiche di programmazione non sono chiare ma
sembrano un rompicapo allora vuol dire che l'analista (che le ha preparate) non ha fatto
un buon lavoro. Il programmatore dovrà contestarle e mai accettarle come
fosse una sfida enigmistica. Quando a scuola si propongono
i programmi come fossero rompicapi matematici, l'allievo acquisisce una concezione
deviata del suo
futuro lavoro.
|
| Il problema è
risolto una volta per tutte. |
Al
contrario il programma applicativo viene continuamente modificato in una
organizzazione.
Dietro nuove esigenze che provengono dal mercato, dal governo,
dall'utenza e da mille altri motivi, l'analista ed il programmatore
modificano il programma. Le statistiche dicono che questo rimane fermo
soltanto qualche mese, ma ci sono programmi che cambiano più volte
nell'arco della settimana. I programmi matematici non cambiano nel tempo
dunque, se lo studente li prende come modello, parte con una concezione
professionale stravolta. |
| La difficoltà
principale risiede nella soluzione del problema |
Il programmatore
interpreta e traduce le specifiche tecniche, cioè progetta il programma (mediante
la pseudocodifica)
poi fà la codifica, quindi fà i test. Spesso viene coinvolto anche nella fase iniziale
di analisi. Dunque il suo lavoro è ben più complesso ed articolato. |
| |
analisi
(specifiche tecniche)
v
progetto del programma
v
codifica del programma
v
test
|
| Poiché il programma
è la soluzione di un problema logico, importante è che funzioni correttamente. |
Ci mancherebbe che una
azienda paghi ed il programma non funzioni a dovere ! E' ovvio che il programma debba dare i dati
richiesti ma
questo non basta. A causa dei continui aggiornamenti cui sarà
sottoposto, il programma applicativo deve essere
ben documentato, cioè deve essere accompagnato da testi e schemi
volti a chiarire i suoi contenuti. La codifica vera e propria deve
essere illustrata con chiarezza anche per evitare truffe o errori di
pagamento quando ci sono.
|
| La logica del programma viene esplicata dal diagramma a blocchi. |
Il programma va progettato
con il diagramma a blocchi oppure con la pseudocodifica che vanno scelti
in modo da facilitare le successive fasi di codifica e di manutenzione. Il criterio è
questo:
si sceglie il diagramma più consono, cioè più simile al linguaggio di programmazione.
Dunque se il linguaggio è
l'Assembler si usa il diagramma a blocchi,
se il linguaggio è simbolico si usa la
pseudocodifica. Poiché il primo linguaggio è alquanto raro, ne
consegue che la pseudocodifica è di gran lunga più diffusa (sull'argomento vedi risposta n. 23).
|
| Mi trovo molto bene con il
diagramma a blocchi perché esplica la logica del problema. |
Nessun ingegnere sceglie il
diagramma di progetto dietro un capriccio personale, ma a seconda dei bisogni oggettivi
del lavoro. La regola da seguire è quella indicata nel punto precedente e
non sarà mai un criterio personalistico.
|
| La logica esplica le corrette
operazioni tra le variabili |
Le operazioni del programma
manipolano i campi informativi che sono precise porzioni di memoria. Soltanto in rari casi
i campi si riferiscono a variabili astratte invece di regola
trattano valori molto pratici
quali lire, dollari, quintali, metri nonché nomi, descrizioni, colori ecc. |
| La trasparenza
non è una qualità necessaria. |
Per una
efficace manutenzione il programma deve risultare chiaro in termini oggettivi e non
soltanto a livello individuale. La programmazione
strutturata ci dà le regole che ne stabiliscono la
trasparenza obbiettiva: 1) Vanno usate le strutture classiche:
- sequenza
- alternativa
- ripetizione
che garantiscono l'oggettiva
leggibilità
dell'algoritmo.
2) Vanno usati nomi
assolutamente trasparenti per i campi che hanno contenuto fisso e
quelli che hanno contenuto variabile, per le etichette ed altro. Es.
Interessi e non Int; Accrediti e non Acc, Movimenti e non Mv che saranno
incomprensibili a chi modificherà il programma.
|
| Il diagramma a blocchi è sufficiente ad
illustrare la logica del problema. |
Il programma è composto da:
- le istruzioni
- le dichiarative
La pseudocodifica [o in
alternativa il diagramma a blocchi] serve per progettare le prime. Il diagramma dei campi che
riporta il flusso dei dati nei vari campi di memoria determina le
dichiarative (vedi risposta 39). I due schemi si completano l'uno con l'altro. Usare soltanto il primo ed
ignorare il secondo causa una fatica maggiore del
necessario ed un minor controllo del risultato.
Purtroppo il diagramma dei campi è spesso usato in modo sciatto ed il futuro
professionista non lo sfrutta per niente.
|
Qualcuno può domandarsi: come mai allora si
continua a presentare la programmazione come soluzione di un problema
logico-matematico?
La risposta è semplice. In
particolari ambienti quali i laboratori scientifici e le case di
produzione del software, le idee
riportate a sinistra non sono scandalosi anzi risultano alquanto utili per ragioni che qui
però non
possiamo analizzare. Questi settori hanno
contribuito a circonfondere l'Informatica di un certo alone lungo i
decenni e, sebbene siano minoritari, hanno
consolidato i luoghi comuni sopra elencati.
Tali settori lavorativi costituiscono
una parte non grande (specie nel nostro paese), invece la più parte degli addetti
informatici si
dedica al software gestionale che si sviluppa nelle banche, nelle
fabbriche, nelle aziende piccole e grandi, nei ministeri ecc. Il problema dunque è eminentemente concreto. La
maggioranza dei giovani che escono dalle nostre scuole non và alla produzione scientifica per la quale sarebbero abbastanza ben preparati, ma nelle aziende e
nelle istituzioni dove invece valgono i principi opposti. Si potrebbe dire
che la scuola prepara per una professione del tutto improbabile, e di fatto genera dei disorientati
i quali poi sul campo si arrangiano come possono.
Un professore una volta mi obbiettò "La scuola
insegna a fare i programmi matematici più impegnativi e dunque non va
criticata. Il calcolo commerciale si sa che è molto più semplice".
Questa
osservazione è valida in astratto perché di fatto anche la programmazione
applicativa è assai esigente. Il calcolo degli interessi bancari pone le
sue difficoltà le quali
non possono essere trascurate
sebbene diverse dalle difficoltà poste dal calcolo di un'orbita satellitare. Ogni lavoro ha i
suoi oneri e gli studenti devono essere preparati esattamente per i
compiti che svolgeranno e non per le cose che non faranno mai.
anno 2001 |
38. Il
problema
è come
impostare
professionalmente
un ragazzo
che farà
il
programmatore... |