Sei sulla pagina 1di 4

SCUOLA DI LABVIEW

05

Training per principianti

MIGLIORARE UN VI ESISTENTE
a cura di Matteo Foini

Quando si eredita un VI da altri sviluppatori, questi possono aver aggiunto delle funzionalit senza fare attenzione al progetto, rendendo sempre pi difficile aggiungere in seguito nuove caratteristiche al VI

obsolescenza del software un problema comune quando ereditate un VI da altri sviluppatori. Esso nasce dal fatto che gli altri sviluppatori possono aver aggiunto delle funzionalit senza fare attenzione al progetto, rendendo cos sempre pi difficile aggiungere in seguito caratteristiche nuove al VI stesso. Una soluzione allobsolescenza quella di effettuare il refactoring del software: un processo di riprogettazione attuato per renderlo pi leggibile e manutenibile, in modo tale che il costo del cambiamento non aumenti nel tempo. Il refactoring cambia la struttura interna di un VI per renderlo pi leggibile e manutenibile, senza cambiarne il suo comportamento osservabile. Questo articolo analizza dei metodi per effettuare il refactoring, presentando alcuni problemi tipici della gestione del codice ereditato.

A. REFACTORING DI CODICE EREDITATO


Scrivete applicazioni software di grandi dimensioni e/o di lunga durata tenendone sempre presente la leggibilit perch il costo della lettura e modifica del software pu verosimilmente superare il costo di realizzazione. Costa di pi ad uno sviluppatore leggere e capire un codice mal progettato che leggere un codice creato per essere leggibile. In generale, sono destinate pi risorse alla lettura e modifica del software che allimplementazione iniziale. Perci i VI facili da leggere e modificare valgono di pi di quelli che non lo sono. Sebbene non sembri intuitivo, un software ben progettato facilita un suo rapido sviluppo in quanto meno suscettibile ad obsolescenza. Se un sistema comincia a diventare obsoleto, potete spendere molto tempo a rintracciare le cause di ci, e questo non produttivo. Anche i cambiamenti possono richiedere pi tempo perch pi difficile capire il sistema.

Figura 1 - VI ereditato

25

SCUOLA DI LABVIEW

05

Figura 2 - VI ereditato dopo il refactoring

Considerate il VI ereditato presente nella fig. 1. Potete eseguire il refactoring del codice come mostrato nella fig. 2. Il codice che ha subito il refactoring fa le stesse cose del codice ereditato, ma pi leggibile. Il codice ereditato vola molte delle linee guida che avete appreso sullo sviluppo dello schema a blocchi. Attraverso il refactoring, potete riprogettare un VI difficile da leggere e manutenere e renderlo leggibile e manutenibile. Questo ne aumenta il valore perch diventa pi facile aggiungere delle caratteristiche o farne il debug. Il processo di refactoring non cambia il comportamento osservabile. Cambiare il modo in cui il VI interagisce con altri client (utenti o altri VI) introduce dei rischi che non sono presenti quando vi limitate a cambiamenti visibili solo agli sviluppatori. Il beneficio di mantenere i due tipi di cambiamenti separati risiede nel fatto che potete gestire meglio i rischi potenziali.

QUANDO FARE IL REFACTORING


Il momento giusto per fare il refactoring quando state aggiungendo delle funzionalit a un VI o ne state facendo il debug. Sebbene siate tentati di riscrivere completamente il VI, dovete riconoscere che c del valore in un VI che funziona, anche se lo schema a blocchi non leggibile. I candidati adatti alla riscrittura completa sono i VI che non funzionano o i VI che soddisfano solo una piccola parte delle vostre necessit. Potete anche riscrivere VI semplici che capite bene. Considerate ci che funziona bene in un VI esistente prima di decidere di effettuare il refactoring. Il refactoring un processo metodico di ristrutturazione di un VI che funziona bene, ma scritto in un modo che ne ostacola la leggibilit, la scalabilit e la manutenibilit.

B. PROBLEMI TIPICI
Quando effettuate il refactoring di un VI, gestite il rischio di introdurre dei bachi facendo piccoli cambiamenti incrementali al VI e verificando il VI dopo ogni cambiamento. Per migliorare lo schema a blocchi, fate piccoli cambiamenti cosmetici prima di affrontare problemi pi impegnativi. Per esempio, pi facile trovare del codice duplicato se lo schema a blocchi ben organizzato e i terminali sono ben etichettati. Sono molti i problemi che possono complicare il lavoro con un VI ereditato. Lelenco seguente descrive problemi tipici e soluzioni di refactoring per rendere i VI ereditati pi leggibili. Lo schema a blocchi troppo disorganizzato Migliorate la leggibilit di un VI disorganizzato spostando degli oggetti allinterno dello schema a blocchi. Per sezioni del VI che sono disorganizzate potete anche creare dei subVI. Per migliorare la leggibilit del VI inserite dei commenti sulle aree che sono disorganizzate.

CONFRONTO TRA REFACTORING E OTTIMIZZAZIONE DELLE PRESTAZIONI


Sebbene possiate effettuare dei cambiamenti che ottimizzino le prestazioni di un VI, non detto che ci debba anche risolversi nel contempo in una procedura di refactoring, che interviene specificamente per cambiare la struttura interna di un VI al fine di renderlo pi facile da leggere, capire e manutenere. Unottimizzazione delle prestazioni non un refactoring perch lobiettivo dellottimizzazione non di rendere il VI facile da capire e modificare. Infatti, lottimizzazione delle prestazioni pu rendere i VI pi difficili da leggere e da capire, cosa che potrebbe essere un compromesso accettabile in certi casi. A volte dovete sacrificare la leggibilit a prestazioni migliori, comunque la leggibilit ha di solito la priorit rispetto alla velocit di esecuzione.

26

SCUOLA DI LABVIEW

Lo schema a blocchi usa nomi di oggetti scorretti e icone poco significative I VI ereditati spesso contengono controlli e indicatori che non hanno nomi significativi. Per esempio, il nome del controllo numero 1, mostrato nella fig. 3, non indica il suo scopo. Il controllo 2 lo stesso controllo, rinominato per rendere lo schema a blocchi pi leggibile e comprensibile.

mi chiamanti aperti del VI con il nuovo nome. Acq Window Temperature.vi un nome pi significativo per il VI. Anche licona del VI dovrebbe chiarire lo scopo del VI. Le icone di default usate per i VI 1 e 2 nella fig. 4 non rappresentano lo scopo del VI. Potete migliorare la leggibilit del VI assegnandogli unicona significativa, come mostrato per il VI 3. Rinominando i controlli e i VI e creando icone dei VI significative, potete migliorare fortemente la leggibilit di un VI ereditato. Il diagramma a blocchi utilizza logica superflua Leggendo lo schema a blocchi nella fig. 5, notate che esso contiene della logica superflua. Se una porzione dello schema a blocchi non va in esecuzione, cancellatela. Capire il codice che va in esecuzione difficile, ma cercare di capire il codice che non va mai in esecuzione inefficiente e rende inutilmente complicato lo schema a blocchi.

Figura 3 - Assegnazione del nome ai controlli 1 Controllo privo di un nome significativo 2 Controllo rinominato in modo pi efficiente

Anche i nomi e le icone dei VI sono importanti per migliorare la leggibilit di un VI. Per esempio, il nome My Acqu.vi, mostrato in alto nella fig. 4, non fornisce alcuna informazione sugli scopi del VI. Potete dare al VI un nome pi significativo salvando una copia del VI con un nuovo nome e sostituendo tutte le istanze del VI con il VI ribattezzato. Un metodo pi semplice consiste nellaprire tutti i programmi chiamanti del VI che volete rinominare, quindi salvare il VI con un nuovo nome. Quando usate questo metodo, LabVIEW cambia automaticamente i link di tutti i programFigura 5 - Logica super flua

Lo schema a blocchi presenta logica duplicata Se un VI contiene della logica duplicata, dovreste sempre effettuare il refactoring del VI creando un subVI per la logica duplicata. Questo pu migliorare la leggibilit e verificabilit del VI. Lo schema a blocchi non impiega la programmazione a flusso di dati Se nello schema a blocchi ci sono strutture sequenziali e variabili locali, il VI con ogni probabilit non fa uso del flusso di dati per determinare il flusso di programmazione. Dovete sostituire la maggioranza delle strutture sequenziali con schemi di progetto basati su macchine a stati. Cancellate le variabili locali ed effettuate collegamenti diretti quando possibile. Luso pi accettabile delle variabili locali quello di far diventare indicatore un controllo.
Figura 4 - Migliorare il nome e licona di un SubVI 1 VI chiamato in modo non significativo 2 VI rinominato in modo pi efficiente 3 Nome e icona del VI significativi

Lo schema a blocchi utilizza algoritmi complicati Gli algoritmi complicati possono rendere un VI difficile da leggere.

27

SCUOLA DI LABVIEW

05

Figura 6 - VI con un algoritmo complicato

Figura 7 - VI sottoposto a refactoring

Quando fate il refactoring di un algoritmo complicato effettuate piccoli cambiamenti per volta e verificate frequentemente il codice, essendo alta la probabilit di introdurre errori. In alcuni casi potete fare il refactoring di un algoritmo complicato usando funzioni integrate in LabVIEW. Per esempio, il VI nella fig. 6 effettua il controllo di nome utente e password rispetto a un database. Potreste effettuare il refactoring di questo VI utilizzando delle funzioni integrate per cercare stringhe, come indicato nella fig. 7. Lo schema a blocchi troppo grande Un VI che ha uno schema a blocchi pi grande della dimensione dello schermo difficile da leggere. Dovete effettuare il refactoring del VI per renderlo pi piccolo. Lazione di scorrimento (scrolling) complica la lettura di uno schema a blocchi e la comprensione del codice.

Potete migliorare uno schema a blocchi troppo grande spostando gli oggetti. Unaltra tecnica per ridurre lo spazio sullo schermo che uno schema a blocchi occupa di creare dei subVI per sezioni di codice allinterno dello schema a blocchi. Se non potete ridurre lo schema a blocchi in maniera da far lo entrare nello schermo, limitate lo scorrimento ad una direzione.

Note sullautore
Laureato in ingegneria nucleare al Politecnico di Milano, Matteo Foini lavora in qualit di Technical Marketing Engineer presso National Instruments Italy

28

Readerser vice.it n. 525