MokaByte Numero 17 - Marzo 1998
Visual Age for Java 
1.0 Enterprise Edition
di
Michele Vignali
La complessità dei progetti software richiede una notevole visione d'insieme a causa della quale diventa essenziale uno strumento di sviluppo che aumenti la produttività e aiuti la gestione e il riuso del codice

 

 

Tutti sanno che, confrontandosi con progetti vasti, è più importante pianificare che non scrivere selvaggiamente migliaia di linee di codice (magari pensando, ma più che altro sperando, che in un secondo momento qualcuno le integrerà per dare vita al prodotto finale).


 

Le potenzialità
Il Visual Age for Java (VAJ) è un ambiente di sviluppo integrato e visuale che supporta l'intero ciclo di creazione di un programma Java, applet o application che sia, secondo le specifiche del JDK 1.1.

È stato fatto uno sforzo per rendere trasparente al programmatore il concetto di file (una vera e propria trappola quando il progetto cresce in dimensioni); nel Visual Age il codice risiede in uno speciale repository e il file (.java, .class o .jar) entra in gioco solo quando si esporta il progetto per distribuire l'applicazione o i suoi sorgenti. Una SmartGuide (il Wizard di IBM) guida alla costruzione di classi, package, interface e componenti in genere; si possono poi eseguire frammenti di sorgente prima di includerli nel progetto e usare il debugger che permette anche la modifica del codice a run-time. Come ogni tool rispettabile anche il Visual Age possiede un controllo di versione (o meglio di edizione) integrato e configurabile. Si può importare codice già scritto sia in forma di sorgente che in forma di bytecode, ed è stata inoltre particolarmente curata la gestione dei Bean (praticamente tutto è un Bean); le risorse (per esempio immagini o audio clip) possono essere importate direttamente in formato jar oppure importando l'intera directory che le contiene. Nell'edizione Enterprise è incluso il Data Access Builder, un potentissimo strumento dedicato per lo più alle imprese e al networking.

Chi ha provato la versione beta del prodotto ([2]) sarà felice di sapere che l'ambiente è stato totalmente rinnovato, è stato abbellito, ma sono stati arricchiti anche i menu (ora per esempio è immediato generare la documentazione in formato HTML) e sono state estese le potenzialità del Visual Builder. La documentazione è inoltre molto ben fatta: infatti, a parte il già citato tutorial esiste un vasto help in formato HTML con un motore di ricerca che permette di eseguire ricerche direttamente dall'interno del proprio web browser; a questo proposito, qualora si sia settato un proxy server, bisogna avere l'accortezza di disabilitarlo per l'indirizzo "localhost".

 

Gli strumenti
Il Workbench è la finestra di partenza: esso contiene un elenco di tutti i progetti in via di sviluppo o terminati. Ogni progetto non è una entità indipendente, ma può usare package di altri progetti (è facile accorgersene semplicemente cliccando sul tab packages). Questo tipo di approccio aiuta a navigare i progetti già esistenti in modo da cercare ed eventualmente riusare codice già scritto. Il Project Browser (eseguibile dal menu Workspace del Workbench) è uno strumento che gestisce l'entità gerarchicamente di più alto livello, ovvero il progetto, che raggruppa tutti gli elementi del programma (classi, package e risorse). Il Visual Composition Editor (VCE) consente di costruire i propri componenti e di collegare tra loro oggetti precostruiti (visuali e non) per determinare il flusso del programma.

È stato realizzato in modo che tutti i componenti creati possano essere Bean con gli ovvi vantaggi che ne conseguono. Il VCE può essere eseguito premendo il tasto destro del mouse e selezionando la voce Open su una qualunque classe di tipo visuale. Lo Scrapbook è una sorta di blocco note più evoluto che permette di "appuntare" frammenti di codice e di testarli molto velocemente avendo però due accortezze: la prima è che bisogna selezionare (evidenziandolo) il codice che si vuole eseguire e l'altra è quella di esplicitare per esteso le classi. Non è possibile quindi scrivere:
 

    Frame f= new Frame("titolo");

Tale forma è invece accettata:
 

    java.awt.Frame f= new java.awt.Frame("titolo");
 

La Console raccoglie l'output non visuale dei programmi (le classiche System.out.println() per intenderci). Con il Repository Explorer invece si "navigano" le versioni di tutti i progetti potendo confrontare per esempio diverse edizioni delle stesse classi. Il Visual Age infatti dispone di un sistema di controllo di versione configurabile tramite il quale si può associare un numero di versione ad ogni classe oppure far sì che la numerazione avvenga in automatico. Il Debugger possiede le funzionalità di ispezione delle variabili, di esecuzione passo passo del codice, inserimento di breakpoint (è ovviamente multithread).

Uscendo dall'ambiente viene salvato l'intero spazio di lavoro (nel corposo file ide.icx) di modo che tutto rimanga come è stato lasciato (viene mantenuta la posizione delle finestre aperte, il codice scritto, ecc.).

Esiste anche una procedura di ripristino dello spazio di lavoro qualora si termini tutto in modo non troppo ortodosso.

 

La creazione di componenti visuali e non
Il processo di sviluppo di un programma può comprendere i seguenti punti:
 


Costruiamo per prova una semplice applicazione che richieda non solo una interfaccia grafica, ma anche un componente non visuale come un algoritmo. L'applicazione in questione è un banalissimo programma per cifrare messaggi: si inserirà nell'apposito spazio il testo da cifrare o quello da decifrare e, a seconda del tasto premuto, si effettuerà la crittazione o la decrittazione. Il progetto si crea dal Workbench semplicemente premendo il tasto destro del mouse nel tab dei progetti e selezionando Add Project; il progetto (che ora è ovviamente vuoto) viene aggiunto alla lista dei progetti: è possibile aprirlo all'interno del Project Browser dopo averlo selezionato. Si supponga ora di dover scrivere l'interfaccia utente dell'applicazione (nella fattispecie una classe chiamata Gui che erediti da java.awt.Frame, in cui disporremo due Button, e un TextField). Ci affidiamo alla SmartGuide del VAJ, premendo il tasto della tool bar che ha indicata la C (quello con la A guida alla creazione di applet). Viene proposta dunque una finestra di dialogo, in cui si deve specificare il nome della classe, il nome di quella da cui eredita nonché package e progetto di appartenenza. Se la classe è di tipo visuale, come in questo caso, viene abilitato il check box che consente di eseguire automaticamente il VCE.
Il Project Browser è suddiviso in diversi tab: Packages, Classes, Interfaces ed Editions che sono viste diverse dello stesso progetto; tramite questo strumento è possibile:
 

Una volta comparso il Visual Composition Editor, la disposizione e l'orientazione relativa degli elementi (TextField, Button ecc.) risulta immediata: è necessario infatti scegliere il componente dalla palette (una specie di toolbar verticale sulla sinistra del VCE) e cliccare nella posizione in cui lo si vuole disporre. Ogni oggetto possiede delle proprietà statiche (riferimento logico usato nel sorgente, i font, il background ecc.) visualizzabili semplicemente con un doppio click sullo stesso.

Siamo dunque giunti alla parte cruciale dell'applicazione: la business logic. Prima di tutto bisogna osservare che questo componente non è visuale. Inoltre, in un'ottica più ampia, potrebbe venire commissionato ad un amico matematico al quale non deve assolutamente interessare (e sicuramente non interessa) come è costruita l'interfaccia grafica. Tale persona dovrebbe infatti sapere soltanto le specifiche: leggere una stringa in chiaro e ritornarne una cifrata e viceversa. Quello che serve è una classe che chiameremo Algoritmo1, e che costruiremo affidandoci ancora alla SmartGuide. Cliccando quindi col tasto destro sul pane Methods e scegliendo la voce New method si possono aggiungere i due metodi che servono (cripta() e decripta()) e il costruttore, scrivendone le semplici implementazioni. Per trattare visualmente anche componenti che non lo sono (come l'algoritmo) si può aggiungere dentro lo spazio di lavoro un Bean (Menu Option, voce Add Bean) che chiameremo ROT13 (il nome è frutto della particolare implementazione dei metodi cripta() e decripta(): poteva essere chiamato dunque DES o IDEA).

 

La connessione dei componenti per generare l'applicazione finale
Per decidere come i vari Bean debbano comportarsi, si usa un potente mezzo: la connection. La connessione è una relazione che collega due elementi sia logicamente (uno dei due potrebbe abilitarsi solo quando l'altro viene disabilitato) che concettualmente (in questo caso l'interfaccia e l'algoritmo si scambiano i dati immessi dall'utente). Le connessioni possono essere di vario tipo e assumono all'interno del Composition Editor colori e forme diverse: più esaurienti spiegazioni si possono trovare nella documentazione in formato HTML e nel tutorial.

Tracciare le connessioni è una operazione semplice: si deve innanzitutto scegliere il componente sorgente cliccandolo con il tasto destro del mouse. Dal popup menu che compare bisogna poi selezionare la voce Connect che consente di tracciare una connessione. Quindi, dal successivo menu, bisogna scegliere la feature (evento, metodo o proprietà) che parteciperà alla connessione. Si sceglie il Bean di destinazione con il tasto sinistro del mouse e si seleziona una delle sue feature; sorgente e destinazione possono coincidere e in alcuni casi possono essere esse stesse delle connessioni. Una connessione tratteggiata è una connessione incompleta e tipicamente bisogna modificarne le proprietà (parametri dei metodi o valori delle proprietà in gioco) per renderla funzionante. Per evidenziare le potenzialità delle connection, arricchiremo l'interfaccia grafica evidenziando alcuni casi interessanti. Supponendo che i due bottoni dell'interfaccia siano disabilitati per default, possiamo pensare di abilitare il pulsante Cripta solo quando l'utente scrive qualcosa nella TextArea.

Questo significa che dovremo collegare l'evento textValueChanged() di Gui.TextArea al metodo setEnable() del bottone Cripta. Purtroppo questo non basta (la connessione risulta tratteggiata quindi incompleta): infatti il metodo setEnable() deve essere invocato con un parametro (true o false). Per completare la connessione dunque basta modificarne le proprietà facendo doppio click sulla stessa, tramite il menu che compare si può modificare in true il valore del parametro.
Questo tipo di collegamento è detto event-method connection (colore verde) diretto da TextArea al Button e in questo caso permette anche di:

Una piccola seccatura è stata riscontrata quando si è cercato di completare la precedente connessione, risultata erroneamente incompleta anche se si era fatto tutto il necessario. L'ostacolo è stato aggirato facilmente anche perché il codice generato era quello giusto, avvalorando l'ipotesi di un problema legato solo all'aggiornamento del modello visuale. Per quanto riguarda i collegamenti tra la parte non visuale (Algoritmo1) e quella visuale (Gui), si supponga di fare in modo che una volta premuto il tasto Cripta, venga invocato il metodo Algoritmo1.cripta() il cui prototipo è:

        String cripta(String p);

e contemporaneamente il testo criptato venga stampato nella TextArea. Innanzitutto colleghiamo con una event-method connection l'evento actionPerformed del pulsante Cripta con il metodo Algoritmo1.cripta().

Il risultato è una linea verde incompleta: infatti, ora dobbiamo gestire anche il valore di ritorno e il parametro del metodo cripta() che cambiano di volta in volta (perché dipendono da cosa l'utente ha scritto). Per completare la connessione bisogna tracciarne un'altra; scegliendo come sorgente la proprietà text (contenuto della zona di testo in forma di String) di Gui.TextArea e come destinazione la event-method connection, comparirà un popup menu che consentirà di scegliere il parametro p. Quest'ultima connessione è una parameter-from-property connection (colore viola) che unisce la TextArea alla event-method connection (completandola).

Analoghe considerazioni si possono fare con i valori di ritorno dei metodi che entrano in gioco nelle connection. Ora non rimane che generare (o meglio esportare) il codice usando la voce Export del menu File del Project Browser. Il VAJ consente di esportare il progetto sia in forma di sorgente (.java) che in forma di bytecode (.class); permette inoltre di produrre archivi JAR molto utili per chi scrive applet.

 

Codice generato: meccanismi e limitazioni
Il sorgente generato si adatta particolarmente bene anche alla stesura di applicazioni basate sul paradigma Model View Controller ([3]) o comunque a situazioni in cui il codice debba essere fortemente strutturato, come nel caso di architetture tipo ISO/OSI o Observer-Observable (di cui si parla in [4]). Di fatto i vari pezzi sono collegati tra di loro solo mediante le connection gestite quasi per intero dal Visual Age (un metodo per connessione). La compilazione avviene automaticamente ogni volta che si salva un metodo o una dichiarazione, cosicché l'eseguibile (chiamiamolo così per semplicità) è sempre aggiornato rispetto ai sorgenti.

Il VAJ compila in modo incrementale: per primi vengono rilevati gli errori di sintassi e poi vengono elencati i cosidetti unresolved problems (come i riferimenti a variabili non ancora dichiarate)

Non è possibile salvare codice che contiene errori di sintassi fino a che questi non sono stati risolti, mentre è possibile salvare metodi che possiedono unresolved problems. Uno dei tipici problemi che nasce quando si usa uno strumento come il Visual Composition Editor, risiede nel fatto che se si aggiunge codice proprio, esso può venire perso poiché il sorgente è rigenerato ogni volta che si modifica il modello.

Il Visual Age oltre a indicare tramite commenti espliciti nel sorgente e icone al fianco dei metodi quali sono i sorgenti che verranno rigenerati, usa i commenti come un vero e proprio riferimento che indica cosa deve essere mantenuto e cosa può essere rigenerato. Il codice generato è piuttosto leggibile per chi conosce i Bean ([1]) e nei punti critici è commentato.

Il meccanismo con cui si genera il codice per i Bean è piuttosto complesso. Si può tuttavia sintetizzare dicendo che per ogni proprietà del Bean si genera:

Per ogni evento, invece, si genera: Per ogni nuovo Listener si genera: Il Visual Age genera il BeanInfo code, che consente l'utilizzo dei propri bean all'interno di qualunque altro strumento di sviluppo conforme con le specifiche Java BeanInfo. Un'ultima nota riguarda il fatto che non vi è più traccia del modello ad eventi del JDK 1.0.2, che invece era gestito aggiungendo handleEvent() nella versione beta del prodotto.

In effetti tale modello era molto scomodo. Tuttavia in questo particolare momento c'è una gran confusione nell'ambiente dei Web Browser: infatti sia Netscape che Internet Explorer non supportano ancora completamente il JDK 1.1 e - almeno commercialmente- si è tagliati fuori se un applet non segue le vecchie specifiche.

 

EAB Enterprise Access Builder
Enterprise Access Builder è, insieme con il Visual Builder, lo strumento di punta del prodotto. Permette di creare classi per l'accesso a database relazionali JDBC compliant, e gestisce transazioni CICS (Customer Information Control System) tipicamente usate in ambiente bancario. Risulta poi facilitato l'accesso a implementazioni C++ in conformità con le norme di JNI (Java Native Interface) nonché la creazione di codice distribuito secondo le specifiche RMI.

L'EAB, fornisce Bean come i JDBCDataStore per gestire le connessioni con i database, oppure le richiestissime liste multi-colonne per gestire le tabelle. I Bean dell'EAB si usano allo stesso modo dei componenti visuali già trattati.

 

Conclusioni
Il prodotto è molto valido, accelera il processo di sviluppo sia in ambiente locale che in ambiente distribuito ed aiuta moltissimo laddove più persone collaborino allo stesso progetto. Inoltre l'esteso supporto dei Bean e l'Enterprise Access Builder conferiscono all'ambiente potenzialità difficilmente riscontrabili in altri concorrenti.

In realtà molti prodotti "Visual" sono visuali solo per metà in quanto sostanzialmente costruiscono interfacce grafiche; il Visual Age invece, tramite le connection, dà la possibilità di costruire visualmente anche i comportamenti dei vari oggetti.

 

Bibliografia
[1] M. Carli, "Realizzazione di un JavaBean", Dev 44/Edizioni Infomedia, 1997.
[2] M. Santin, "IBM Visual Age for Java", Dev 44/Edizioni Infomedia 1997.
[3] C. Pescio, "Model-View-Controller,Document-View,E/P/T-Glue: Evoluzione di un paradigma", Computer Programming Luglio 1996/Edizioni Infomedia.
[4] M.Vignali, G.Rimassa, P.Marenzoni, G.Destri, "Observer in Java: esempio di utilizzo dei design pattern", Computer Programming n.61/Edizioni Infomedia, 1997.
[5] http://www.software.ibm.com/ad/vajava.
[6] http://cosmo.sgi.com/products/studio/code.
[7] M. Sciabarrà, "Il Microsoft Visual J++ 1.1", Computer Programming 62/Infomedia, 1997.
 
 
Michele Vignali è laureando in Ingegneria Elettronica presso l'Università di Parma. I suoi interessi comprendono l'ingegneria del software nell'ambito della quale si occupa di programmazione concorrente e distribuita, con particolare attenzione alle basi di dati federate e a Java. 

 
 
 
 

 
MokaByte rivista web su Java

MokaByte ricerca nuovi collaboratori
Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it