Valutazione dei costi di migrazione tramite metriche di complessità del codice

4 
 
Introduzione 
Nello scenario economico odierno, le imprese si trovano sempre più spesso a confrontare 
le opportunità presentate dalle nuove tecnologie e il parco applicativo esistente in rapida 
obsolescenza. 
Il costo dell’adeguamento dai sistemi informativi in dotazione alle nuove piattaforme, 
imposto dall’evoluzione tecnologica, spesso può assumere entità rilevante e pertanto 
deve essere continuamente sottoposto a revisioni che ne giustifichino la fattibilità. 
La mancanza di tecniche universalmente accettate per valutare costi e benefici 
nell’adeguamento fa si che tale sforzo sia spesso visto più come una voce di costo, che 
non come un investimento generante valore aggiunto, frenando in questo modo gli sforzi 
d’innovazione richiesti alle imprese italiane, che in questi ultimi anni hanno ridotto 
sempre più il budget a esso dedicato (si parla di un 5% in meno ogni anno), causando 
conseguentemente un notevole divario tecnologico rispetto alle concorrenti americane. 
In questo contesto, assumono sempre più valore e importanza le piattaforme che 
permettono di evolvere il codice applicativo esistente in maniera semi automatica 
garantendo un risparmio di costi rispetto alla completa riscrittura, ma soprattutto 
permettendo di stilare in maniera relativamente semplice e veloce lo sforzo necessario 
ad una migrazione completa: infatti con questi sistemi è possibile identificare subito le 
parti che non possono essere migrate automaticamente. Queste piattaforme permettono 
in generale un risparmio dei costi e un’evoluzione del parco applicativo in uno stato tale 
da poter permettere l’innovazione dei sistemi ad un costo sensibilmente ridotto, 
riducendo considerevolmente il lavoro necessario all’adeguamento. 
C’è inoltre da considerare che,  se anche questi tool non aggiungono direttamente 
funzionalità alle applicazioni esistenti, tuttavia, nel corso degli anni,  i framework 
applicativi hanno avuto forti evoluzioni dal punto di vista dell’interoperabilità, della 
facilità di scrittura di codice e dell’integrazione tra vari componenti. 
Ad esempio la migrazione di applicazioni da Visual Basic 6.0 al framework .Net permette 
di beneficiare delle evoluzioni intervenute negli ultimi anni nei linguaggi full object 
oriented e degli IDE ad esso associati (visual studio); VB 6.0 infatti non si configura come 
linguaggio full object oriented, risultando invece un’evoluzione, ancorchè solida, di un 
linguaggio tipicamente procedurale con supporto agli oggetti che, per molte funzionalità, 
5 
 
si appoggia ancora al substrato COM preesistente, quindi librerie esterne spesso scritte in 
C++.  
VB.NET al contrario risulta già nativamente object oriented e gli ambienti di sviluppo che 
ne permettono la modifica/compilazione, sono dotati di strumenti molto più evoluti, per 
esempio per il refactoring, il testing, l’ispezione di moduli esterni e lo stesso debugging 
che consentono di ottenere a costi minimi un codice più manutenibile e meglio 
strutturato (in quanto il Framework .Net è una piattaforma full object oriented e 
incorpora dalla nascita funzionalità in passato privilegio di estensioni di terze parti), ma 
(ancorché non in maniera automatizzata) permette , per esempio attraverso il supporto 
nativo ai web services, una maggiore integrazione con altre piattaforme anche legacy, 
riducendo lo sforzo di ampliamento delle funzionalità nell’interoperabilità con sistemi 
esterni (per esempio SAP). Per tutte queste ragioni, assume pertanto una particolare 
rilevanza la possibilità che i tool di migrazione offrano strumenti di valutazione e 
supporto all’intervento umano in fase di analisi del parco applicativo, insieme al fatto che 
possano fornire una stima valutabile, da parte di un tecnico esperto, dello sforzo 
necessario a migrare una serie di applicazioni da una piattaforma/sistema di origine ad 
una piattaforma di destinazione (Assessment Applicativo). 
Nei capitoli che seguono verranno illustrate tali funzionalità applicate ad un tool di 
migrazione automatica, di applicazioni scritte nella piattaforma Lotus notes alla 
piattaforma .Net. 
 
Il primo capitolo illustra più dettagliatamente le finalità del progetto, facendo una 
panoramica sul tool di conversione e sui parametri necessari a stimare l’economicità del 
suo utilizzo. Il Secondo capitolo tratta delle varie metriche che sono state sviluppate con 
il fine di poter misurare la complessità del software. Il terzo capitolo vuole approfondire i 
parametri per la misura della migrabilità del codice. Il quarto capitolo spiega in dettaglio 
come funzionano le classi implementate all'interno del tool e come vangono identificate 
e utilizzate le issue. 
 
6 
 
Scopo del progetto 
Lo scopo del progetto è la valutazione della convenienza e costo della conversione 
automatica del  codice mediante l’utilizzo di un tool isofunzionale dalla piattaforma 
LotusNotes a tecnologie Microsoft quali C#, SQL, Silverlight e Sharepoint; questa 
valutazione andrà fatta tenendo conto di una serie di parametri quali numero di righe di 
codice, complessità ciclomatica e issue: le prime due metriche servono a darci un’idea di 
quanto sia complesso il codice che stiamo analizzando mentre gli issue sono 
problematiche generate dal tool di migrazione quando non è possibile tradurre in 
maniera automatica per via dell’impossibilità di mantenere l’isofunzionalità all’interno 
della conversione.  
La conversione del  codice da un linguaggio di programmazione ad un altro è un 
procedimento complesso che può esser fatto in maniera automatica, ma non sempre si 
avranno dei risultati soddisfacenti poiché per via della disparità tra i framework , il tool 
riuscirà a convertire solo una parte di tutto il codice e il resto dovrà essere fatto a mano; 
inoltre non è neppure detto che l'output prodotto esegua correttamente la funzione 
originaria. Quindi si evidenzia un primo problema costituito dall’effort necessario per 
comprendere a priori se è conveniente la conversione automatizzata: scarteremo in 
partenza programmi che hanno un utilizzo nel tempo molto limitato dal momento che in 
questo caso avremmo uno spreco inutile di risorse, mentre favoriremo applicazioni con 
un lifetime elevato ed un'alta stabilità (cioè con necessità di pochi aggiornamenti); è su 
questo tipo di applicazione che dovremo valutare se è conveniente la conversione 
automatica: Per poter decidere verranno presi in esame i tre parametri già citati 
precedentemente: 
 ξ Numero di righe di codice (LOC) 
 ξ Complessità ciclomatica 
 ξ Issue 
I primi due parametri applicati su ogni porzione di codice da migrare serviranno per poter 
capire a priori la sua qualità; una complessità ciclomatica troppo elevata (secondo 
McCabe non dovrebbe superare il valore di 10) è indice di codice mal scritto che, se 
migrato in modo automatico, continuerà a mantenere gli stessi difetti causando sprechi 
di memoria e cpu e risultando di difficile manutenibilità futura. Per questo motivo, anche 
se il tool fosse in grado di convertire senza generare issue, la soluzione migliore potrebbe 
esser quella di riscrivere manualmente il codice in questione. Inoltre, dopo aver stabilito 
7 
 
che per un determinato programma Lotus Notes è conveniente utilizzare il tool 
automatico, sarà indispensabile anche quantificare il lavoro necessario per riscrivere le 
parti di codice che il parser non è riuscito a convertire. Sono due i motivi per cui il tool 
non riesce nella conversione e genera issue:  
 ξ Non può riconoscere la funzione che sta analizzando poichè non è ancora stata 
implementata. 
 ξ La funzione non ha equivalente nella piattaforma di destinazione (per le 
caratteristiche della piattaforma di destinazione tale funzione non ha significato).  
Ogni issue che il tool genera dovrà esser salvato precisando la causa della sua creazione, 
il codice che lo genera e la relativa complessità ciclomatica, così si avrà modo di 
quantificare e pesare la parte di programma che dovrà esser convertita manualmente, 
cosa indispensabile per poter presentare al cliente, che vuole migrare le sue applicazioni 
LotusNotes, una stima dei costi da affrontare, quasi interamente determinati dalla 
quantità di lavoro di conversione manuale. 
 
Migrazione isofunzionale automatizzata del codice e metriche di 
misura della migrabilità 
La traduzione automatica del software è un processo gestito da strumenti meccanici 
(elaboratori) che si occupa della traduzione di codice sorgente  
 ξ Da un linguaggio di programmazione di origine ad un linguaggio di 
programmazione di destinazione 
 ξ Da una piattaforma di origine ad una piattaforma di destinazione differenti 
preservando l’isofunzionalità del codice ovverosia rispettando nel programma di 
destinazione le stesse funzionalità del programma di origine 
La problematica della migrazione del codice sorgente storicamente è divenuta di 
importanza sempre maggiore in funzione dell’accelerazione dell’evoluzione delle 
strutture dei calcolatori e dei linguaggi di programmazione. 
In particolare si possono individuare tre milestone significative: 
 ξ L’evoluzione dell’hardware da sistemi legacy a sistemi distribuiti 
8 
 
 ξ L’evoluzione del paradigma di programmazione da linguaggi logico/procedurali 
all’object oriented 
 ξ L’introduzione di framework di sviluppo applicativo 
Nella prima milestone i programmatori si sono trovati di fronte ad una nuova architettura 
di computing non più incentrata sul singolo mainframe ma distribuita su livelli 
architetturali distinti. 
Codice progettato per essere eseguito in modalità client/server doveva essere 
reingegnerizzato in modo da adattarsi alla nuova architettura. 
In questa fase sono stati progettati i primi tool di migrazione automatica, per i quali 
tuttavia non si presentava la problematica della migrabilità: trattandosi di un passaggio 
tra un linguaggio procedurale di origine ad un linguaggio procedurale di destinazione, è 
garantita la totale copertura funzionale tra il codice sorgente e il codice generato. 
Nella fase di passaggio tra linguaggi logico procedurali a object oriented sono cominciate 
ad emergere le prime difficoltà nel processo di migrazione, non tanto dal punto di vista 
della migrabilità in sé, quanto piuttosto nella qualità del codice generato. 
Il paradigma Object Oriented, difatti, organizza il codice in costrutti di tipo classe che 
incapsulano i dati (proprietà) e le operazioni sugli stessi (metodi), qualità che non erano 
presenti nella generazione di linguaggi precedenti. 
E’ in questa fase che si sviluppano le tecniche di refactoring, necessarie, in fase post-
migrazione, a riallineare il codice migrato per rispettare il modello ad oggetti e garantirne 
la manutenibilità nel tempo. 
Nell’ultima milestone, la composizione di funzionalità in framework applicativi ha 
introdotto la problematica della migrabilità del codice, non come processo di passaggio 
da un codice scritto in un certo linguaggio ad un codice scritto in un linguaggio differente, 
quanto piuttosto da un codice scritto per supportare un framework (che incorpora una 
serie di funzionalità native) eventualmente esteso tramite oggetti custom, ad un codice 
di destinazione che necessariamente deve essere eseguito su un framework target, che 
potrebbe non supportare nativamente le funzionalità native di origine, piuttosto che 
supportare nativamente le funzionalità custom del framework applicativo di origine. 
9 
 
 
Dato l’universo del discorso che comprende gli oggetti del framework di origine 
(Framework A) e l’universo del discorso che comprende gli oggetti del framework di 
destinazione (Framework B), definiamo copertura funzionale l’intersezione tra i due 
universi del discorso, ovvero quanto nel framework di destinazione è supportato rispetto 
al framework di origine. 
Definiamo inoltre migrabilità automatica di un programma la percentuale di codice 
applicativo di un programma coperto funzionalmente (che ricade pertanto 
nell’intersezione tra i due universi del discorso) rispetto alla quantità complessiva del 
codice. 
E’ importante considerare che la migrabilità automatica non è un concetto legato al 
codice (che è comunque interamente convertibile in codice di destinazione), quanto ai 
framework funzionale di origine e destinazione. 
 
Storia di Lotus Notes 
Le radici di Lotus Notes risalgono al 1973, quando venne rilasciata la prima release 
chiamata PLATO, inventata da un professore universitario di ingegneria, Don Bitzer, che 
aveva ideato l’applicazione con l’intento di poter utilizzare una rete di computer per