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

La traduzione automatica del software è un processo gestito da elaboratori che si occupa della traduzione di codice sorgente da un linguaggio di programmazione d’origine a uno di destinazione, rispettando nel programma di destinazione le stesse funzionalità del programma d’origine. La problematica della migrazione, nel contesto moderno dove l’evoluzione delle tecnologie informatiche è in continuo aggiornamento, assume sempre maggior importanza. Le imprese, soprattutto in Italia, soffrono di un’arretratezza tecnologica che preclude la dinamicità dei processi aziendali e diventa quindi importante l’aggiornamento dei propri sistemi al fine di cercare di ottenere un vantaggio sulla concorrenza, mantenendo, allo stesso tempo, la spesa da sostenere nei limiti del budget disponibile. L’adozione di soluzioni di migrazione automatica può esser di grande aiuto alle imprese poiché, se utilizzate in maniera intelligente, sarà possibile avere un prodotto di buona qualità a costi notevolmente ridotti.
Si possono individuare tre tipi di migrazioni:
L’evoluzione dell’hardware da sistemi legacy a sistemi distribuiti
L’evoluzione dal paradigma di programmazione da linguaggi logico/procedurali all’object oriented
L’introduzione di framework di sviluppo applicativo
Il terzo punto rappresenta la migrazione più complessa perché dà origine a problematiche legate alla migrazione di funzioni native del linguaggio; Il framework incorpora funzionalità specifiche che saranno differenti tra il linguaggio d’origine e quello di destinazione; viene introdotta 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), ad un codice di destinazione che necessariamente deve essere eseguito su un framework target e che potrebbe non supportare nativamente le funzionalità d’origine. È in questo contesto che si colloca il tool di migrazione su cui ho lavorato durante il mio stage in Avanade. Questi è stato realizzato con il fine di poter portare in maniera semi-automatica applicazioni scritte in LotusNotes a piattaforme più recenti e funzionali quali C# e Silverlight (utilizzato per la parte front-end). Il sistema LotusNotes, inventato nel 1973 da Don Bitzer, professore universitario, ha l’intento di poter utilizzare una rete di computer per l’apprendimento automatizzato, mediante l’utilizzo di funzionalità collaborative simili alle moderne chat, e-mail e condivisione file. Successivamente è evoluto in un software commerciale dedicato alla gestione interna di grandi aziende. Di anno in anno sono state rilasciate nuove release con relativi aggiornamenti e nuove funzionalità fino ad arrivare alla versione odierna, tutt’oggi in commercio, che seppur perfettamente integrata con il web e tutte le altre tecnologie non esistenti negli anni 80’ si può considerare obsoleta, almeno dal mio punto di vista, in quanto nata da un’idea vecchia di quarant’anni. Si parla quindi di conversione semi-automatica per l’inevitabile differenza tra i framework dei due linguaggi; ci sarà quindi una parte del codice del programma sorgente da convertire in modo automatico ed un’altra dovrà essere gestita manualmente da un capace programmatore. Il compito assegnatomi nello stage, è stato quello di identificare quest’ultima parte, dandole un peso utile a capirne la complessità e quindi il relativo costo in termini di risorse umane per la sua traduzione. Per fare questo mi sono dovuto documentare sulle varie metriche di misura del codice, come ad esempio quella di Albrecht, COCOMO e infine McCabe, che è stata la metrica che ho implementato all’interno del tool per il suo compromesso trà affidabilità e semplicità; (viene costruito il grafo equivalente di un programma formato dai cammini indipendenti che si creano al suo interno, per poi trovare il valore rappresentante il numero ciclomatico V(G)= e – n + 2p dove e= # archi, n=# nodi mentre p rappresenta il numero di componenti connesse). Una volta identificato e pesato un token di codice non migrabile in automatico dovrò generare un issue contenente tutte le informazioni disponibili tra cui la causa della mancata conversione che può essere dovuta a:
Il tool 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).