oocobol PDF Stampa E-mail

OO Cobol

(object oriented)

Con lo standard ansi 2002 il linguaggio cobol arrivato a 50 anni di storia, si allinea agli standard del mercato offrendo, oltre alla sua  consueta robustezza e velocità di esecuzione: programmazione object oriented, supporto di  interfacce gui, accesso a data base relazionali, integrazione con java, chiamate  a funzioni api.

Per scrivere software definito “critico” in ambito gestionale si e' spesso  usato, per le sue caratteristiche funzionali,  il Cobol (COmmon Business Oriented Language). Con l’evolversi dei sistemi di programmazione sono stati implementati nuovi linguaggi e nuove metodologie di gestione del software. Attualmente uno dei sistemi di programmazione piu’ utilizzati  e’ Java, un linguaggio gratuito, object oriented, multi piattaforma etc. Obiettivo di questo scritto non e’ ripercorrere storicamente lo sviluppo dei linguaggi di programmazione, ma fornire un quadro d’insieme relativo al modus operandi della nostra azienda e di come siano stati affrontati i problemi relativi all'aggiornamento e miglioria dei sistemi, anche alla luce delle nuove tecnologie disponibili.  

Con l’avvento di Windows 95 e le sue successive versioni, il principale problema che i programmatori cobol hanno dovuto affrontare era come attribuire alle procedure un’interfaccia gui (graphical user interface); 25 anni fa era normale scrivere su main-frame o mini computer, anche per noi che allora operavamo su sistemi operativi GCOS, della Honeywell bull su macchine DPS6, le famose ‘schermate verdi ‘rappresentavano la normalita’. Il dover sviluppare ed affrontare nuove metodologie per chi come noi, ha continuato ad operare trasferendo il proprio core-business nell’ambiente Pc,  garantire la robustezza raggiunta rappresenta la nostra condizione inamovibile di base. Le applicazioni cobol disegnate 20 fa, che attualmente (r)esitono subiscono continuamente operazioni di restyling, che oltre ad essere onerose richiamano di produrre l’effetto di disgregare autonomatismi ed affidabilita’

 


  

Ad un certo punto ci si e' resi conto che per passare su interfaccia grafica i prodotti andavano quanto meno seriamente reingegnerizzati. Altre aziende hanno ovviato abbandonando il linguaggio cobol  riscrivendo da capo il codice fruendo semmai dell'analisi dei dati, quando la stessa risultava essere corretta e appropriata ai processi. Del resto le soluzioni offerte dai principali produttori di compilatori erano ancora poco evolute verso la grafica e in questi casi c'e' stato quindi chi ha preferito, nel dubbio, cambiare proprio il linguaggio verso altri più "alla moda" (leggasi Visual basic..).

La nostra  "fortuna",  se così si puo' dire,  e' stata l'aver usato un case di generazione codice,  scritto in casa,  che   aveva standardizzato molto le procedure garantendo  una buona separazione dell'interfaccia dai flussi di dati e relativi controlli. Così nel 2001 abbiamo iniziato a licenziare i primi prodotti su interfaccia nativa window.  Nei successivi 3 anni sono state svolte importanti attività di rimodellazione degli applicativi consentendo di fornire nuovissimi prodotti che avevano però il "motore" o kernel consolidato da anni di utilizzo e miglioria.

Nello specifico l'esempio che si desidera riportare e' quello della procedura WinStipe, evoluzione Windows della versione dos (scritta in cobol Microsoft) usata dal 1990 al 2001 dai nostri clienti. La versione windows ha richiesto circa 6 mesi di revisione per il rilascio della prima versione a fine 2001. Da allora Il prodotto viene sistematicamente aggiornato (data la natura della problematica)  quasi settimanalmente.

L'utilizzo degli oggetti ha poi sensibilmente migliorato le caratteristiche, le perfomances, e non ultima, la rapidità con la quale notoriamente e' necessario sottoporre le nuove release di scrittura del nuovo codice, test e rilascio. Và comunque detto che anche per noi, come tutti i programmatori cobol, tradizionalmente 'funzionali', (abituati quindi all'approccio per funzioni)  l'uso del paradigma degli oggetti, (che può apparire inizialmente ostico) ha richiesto applicazione e studio.

Tuttavia per quelle aziende,  come la nostra, che devono coniugare tutte le attività di progettazione codice, test, marketing logistica riferita all'Azienda, ai clienti, al mercato in generale,  si rende imperativo salvaguardare anni di esperienza a beneficio di una maggiore produttività e professionalità, con la consapevolezza di dover sempre offrire un prodotto di alto livello. Evidentemente poi, per il contesto nel quale siamo chiamati ad operare, oltre a dover saper programmare dobbiamo avere una approfondita conoscenza delle materie amministrative  per le quali scriviamo i software e in questo senso ciascuna abilità sia tecnica che normativa e' necessaria sia per l'analisi che per il problem solving. Quindi maggiore affidabilità e migliore produttività non possono che avere effetti benefici anche sul piano generale dell'organizzazione lavorativa.

OO Cobol, dalle funzioni alle classi

 

Capire come la programmazione ad oggetti può influenzare (in positivo) le caratteristiche di un prodotto software e' utile per poter da parte di un cliente avere una miglior consapevolezza delle potenzialità del prodotto utilizzato e, laddove  non disponibili,  poter meglio indirizzare la ricerca sul mercato e valutare con un minimo di spirito critico la robustezza di quanto proposto dalle aziende produttrici.

 
Da l'altro lato e' utile inoltre per l'azienda che sta valutando conversioni o restyling del proprio software perche' adottare una programmazione ad oggetti e' comunque il primo passo per poter poi eventualmente passare ad altro linguaggio di programmazione.

Tipicamente i dati, nelle modalita' di scrittura del codice a funzioni, sono un po' visti in modo marginale rispetto agli algoritmi usati per accedervi. Non e' quindi infrequente che ad un certo dato vi si possa accedere in modalita' diverse e talvolta nell'ambito di progetti di migliaia di righe (facilmente si arriva oltre le 20.000)  ciò sia foriero di difetti difficilmente sistemabili ovvero di problemi che a runtime (esecuzione del codice) rappresentano un grosso problema per la verifica da parte del programmatore. Inoltre, una volta eventualmente corretti, qualora ci si impegni in un nuovo progetto, il riutilizzo degli stessi impone comunque una revisione talvolta sostanziale e quindi non priva di rischi nella fase di successivo assemblamento.

Nella programmazione ad oggetti invece l'attore principale e' proprio il dato. Una volta stabilite le proprietà e i metodi di accesso a tale dato essendo gli stessi incapsulati e' impossibile che si possano creare situazioni ridondanti o critiche. La classe rappresenta in questo contesto l'entità astratta nella quale un particolare dato e' incapsulato, protetto e processato e contiene le azioni specifiche per gestire tale dato. 

E inoltre sorprendente di quanto si possa semplificare il codice arrivando come prima conseguenza (ed in modo automatico e naturale) ad una importante distinzione tra il codice dell'interfaccia utente dai quello dei processi interni computazionali e algoritmici.
Vediamo ad esempio la differenza tra una procedura di controllo della data e una  una classe deputata a controllare gli oggetti di tipo data. In un normale programma cobol a funzioni tipicamente potremmo ad esempio avere le seguenti istruzioni :

 

move campo-video       to data-da-controllare.
 perform controllo-data thru ex-controllo-data.
 if sw-errore = "SI"
perform segnala-errore     ...istruzioni condizionali .
.
.
else
...istruzioni condizionali ...
end-if.


Vediamo in sequenza cosa accade:

 

viene acquisito il valore dal campo maschera (sia essa un form html, una screen section ..).

 

viene controllata  la validità del campo tramite utilizzo di una perform  (questa tipicamente inserita in una  copy) o ad una
call ad una sub-routine presente in altra libreria

 

si puo proseguire ovvero ripetere l'input qualora i controlli eseguiti abbiano riportato un codice di errore.


Problema: il programmatore puo' .."dimenticarsi"  di controllare una data, e'  sufficiente un errore in una assegnazione perche' la funzione di controllo sia invalidata. Insomma tutti i classici problemi. Qualora il programma abbia decine di campi data  anche ammesso che si faccia sempre copia e incolla il potenziale errore e' sempre presente.


Domanda: Come puo' in questo caso un oggetto venirci incontro ?

 
Vediamo intanto la sintassi come apparirebbe
 

move campo-video to valore-data of classe-data
if data-errata of classe-data
istruzioni ....
else
 istruzioni ....
 end-if.


Ora gli attributi della classe sono incapsulati, come da oo classico, l'incapsulamento consente quindi che l'accesso avvenga se e solo se si usa il canale deputato dalle tipiche funzioni "get" e "set". e internamente, nel cuore della classe avremo il metodo di controllo della validità del campo data con l'eventuale assegnazione del flag di errore nelle variabili di factory della classe  (nello specifico l'ipotesi e' di una classe che non istanzia oggetti)
Nel nostro programma esiste solo il richiamo alla classe CLASSE-DATA,  l'istruzione di assegnazione move ...in realtà e' una chiamata al metodo SET-data  e all'interno esiste anche il controllo della validità. Il flag di errore e' un attributo della classe stessa.


move data-nascita-video to data-nascita of dipendente

e delegare alla "move" intesa come trasporto dei dati i metodi di controllo e verifica formale ed eventuale  scrittura o aggiornamento nel record di riferimento o comunque processo. E quindi poter, ad esempio, verificare se il dipendente inserito sia minorenne e operare tutti i controlli che formalmente devono essere prodotti su un record di tale flusso.

Il codice diventa quindi molto piu' leggibile, privo della verbosità che a volte (giustamente) viene indicata come grosso handicap per il linguaggio cobol (rispetto ai suoi piu' recenti cugini) anche se la stessa e' generalmente sopportata se non altro per la chiarezza di sintassi che comunque il linguaggio ha.

Il sorgente del nostro programma sarebbe molto più pulito e decisamente facilmente implementabile e migliorabile. La riusabilità dello stesso diventerebbe quindi una pratica comoda ed essenziale in quanto una futura revisione della classe non impatterebbe troppo tutto il codice  che la utilizza.