Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
05
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.
Figura 1 - VI ereditato
25
SCUOLA DI LABVIEW
05
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.
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.
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
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