Introduzione
Nella
mia breve esperienza di progettista software ho avuto modo di verificare
l'importanza di disporre di strumenti di lavoro adeguati: un modeler UML
e un Editor di codice. Il passaggio dalla fase di modellazione a quella
di implementazione e' un momento critico, durante il quale viene a mancare
un supporto valido da parte dei modeler tradizionali, come Rational Rose.
TogetherJ,
un modeler UML sviluppato dal team di Peter Coad, nasce col preciso scopo
di eliminare questo gap, supportando il progettista lungo tutte le fasi
del lavoro, grazie ad una funzionalita', definita simultaneous round-trip
engineering, che rappresenta una grande novita' nel panorama dei Modeler
UML.
Diagrammi di Classe
e Simultaneous Round-Trip Engineering
Un
progetto sviluppato in UML ha la sua espressione piu' elevata nei diagrammi
di classe. I diagrammi di classe forniscono una vista simbolica su una
collezione di classi java, con una corrispondenza semantica precisa tra
gli uni e le altre (vedere l'articolo "Ciclo di Vita del Software e Reverse
Engineering" <<aggiungere link>> in questo stesso numero di
MokaByte). I modeler oggi in commercio permettono sia la generazione di
codice a partire dai diagrammi, che la generazione di diagrammi di
classe a partire dall'analisi dei sorgenti. TogetherJ si spinge un passo
avanti, permettendo per la prima volta di eseguire queste due operazioni
contemporaneamente e in tempo reale: mentre l'utente disegna diagrammi
di classe, TogetherJ produce il codice corrispondente; quando invece l'utente
elabora il codice, TogetherJ aggiorna i diagrammi. Persino la documentazione
del progetto viene riportata nel codice sotto forma di javadoc.
Questa
funzionalita', denominata Simultaneous Round-Trip Engineering, aggiunge
una dimensione nuova alla progettazione, fornendo al Capo Progetto un feedback
straordinario dal lavoro degli implementatori.
Lavoro di gruppo
Un'altro
aspetto esclusivo di TogetherJ e' la possibilita' di coordinare il lavoro
di un team di progettazione e sviluppo. Dal momento che il tool mantiene
la descrizione dei diagrammi direttamente nel codice (e alcuni files generati
all'interno di ogni package), e' possibile aprire piu' di un progetto sullo
stesso insieme di classi. Se due o piu' utenti lavorano allo stesso programma
da macchine diverse collegate in rete, le modifiche apportate da un membro
del team saranno visibili immediatamente a tutti gli altri.
Ovviamente
viene data la possibilita' di definire i permessi di accesso su ogni package,
in modo da suddividere i compiti tra i membri di un team. Se si desidera
che due sviluppatori lavorino in parallelo sullo stesso programma java,
e' possibile creare un progetto per ognuno di loro, in modo che entrambi
abbiano accesso all'intero albero dei package in lettura, ma con permessi
di scrittura differenti. Se si desidera affidare all'utente A lo sviluppo
del package UserInterface, si puo' creare per lui un progetto con permessi
di lettura-scrittura su quel package. L'utente B, a cui si affida lo sviluppo
del package ProblemDomain, potra' navigare liberamente nel package UserInterface,
studiarne i diagrammi ed utilizzarne le classi, ma non potra' in alcun
modo modificarne la struttura o il codice.
Pattern
Un'aspetto
che meriterebbe di essere approfondito in un articolo a parte e' la possibilita'
di utilizzare pattern standard, o di svilupparne di nuovi. TogehterJ comprende
una collezione dei pattern piu' usati, comprensivi di diagramma di classe,
guida all'implementazione e documentazione javadoc. L'utente deve solo
scegliere il pattern e il package di destinazione, e TogetherJ provvedera'
a generare le classi che compongono il pattern con gli opportuni collegamenti.
Personalizzazione
dell'ambiente
Ogni
aspetto del programma e' configurabile, dalla composizione di menu e toolbar
ai dettagli sulla generazione di codice, dai compilatori agli editor di
sorgente esterni. Gli utenti Unix gradiranno in particolare la possibilita'
di integrare nell'ambiente di sviluppo qualunque tipo di filtro o tool
a riga di comando. Le scelte a disposizione sono tantissime, e vale la
pena di esplorare a fondo i pannelli di controllo.
Descrizione dello
Spazio di Lavoro
Lo
spazio di lavoro e' organizzato in cinque aree, personalizzabili tramite
pulsanti e pannelli di controllo:
-
Explorer,
situato in alto a sinistra, permette di navigare all'interno del progetto
Inspector, in basso a sinistra, mostra i dettagli dell'oggetto attualmente
a fuoco (autore, documentazione, stereotipi ecc)
-
Diagram
Pane, in alto a destra, contiene i diagrammi UML
-
Editor
Pane, al centro a destra, mostra il codice dell'oggetto attualmente a fuoco
-
Message
Pane, in basso, mostra l'output di sistema, del compilatore e dell'ambiente
di esecuzione.
Organizzazione
dei Progetti
Attraverso
l'Explorer e' possibile vedere come vengono organizzati i progetti in TogetherJ.
Un progetto e' composto da un albero di packages, con un'organizzazione
gerarchica che puo' essere diversa da quella dei files su disco. Ogni package
contiene classi, interfacce e diagrammi di ogni tipo. Contrariamente a
quanto avviene su Rational Rose, non esiste una gerarchia predefinita (Use
Case View, Logical View e Component View). L'utente e' libero di organizzare
il progetto come vuole, presentando diagrammi con diverso grado di dettaglio
nello stesso package, o creando un package speciale per la vista di alto
livello.
Dal
momento che le classi presenti nell'albero dei package corrispondono a
sorgenti java, la vista sul progetto cambia ogni qualvolta si interviene
sul codice, anche usando tool esterni. Come gia' detto, se i package si
trovano in rete su un file server a cui accede piu' di un utente per volta,
le modifiche operate da un membro del team saranno visibili immediatamente
anche agli altri.
E'
possibile aggiornare l'albero dei package in qualunque modo, rinominando
package o classi, spostando classi da un package ad un altro, rimuovendo
o aggiungendo interi package usando il cut & paste: il motore di TogetherJ
risolvera' in modo automatico e trasparente tutti i riferimenti presenti
nel codice.
Diagrammi
TogetherJ
mette a disposizione tutti i diagrammi previsti dalle specifiche UML, compresi
gli Activity Diagram, non presenti su tutte le versioni di Rational Rose.
E' piacevole notare l'aderenza ad alcune specifiche UML recenti, non presenti
su Rational Rose, come la rappresentazione dei costrutti condizionali e
dei blocchi nidificati nei Diagrammi di Sequenza. Esiste inoltre una interessante
funzione di Reverse Engineering, che permette di estrarre un diagramma
di sequenza da una porzione di codice (vedere l'articolo "Come funziona
il Simultaneous Round Trip Engineering" in questo stesso numero di
MokaByte).
Ecco
qui di seguito alcuni screen shot che mostrano i risultati delle varie
operazioni di progettazione grafica
L'Explorer
mette a disposizione il Navigator, uno strumento presente in molti programmi
di grafica, utile quando si lavora su diagrammi molto complessi. Muovendo
il puntatore sopra una rappresentazione in miniatura del diagramma, possiamo
spostare velocemente la vista sul diagramma vero e proprio.
Diagrammi
di Classe
I
diagrammi di classe meritano una trattazione piu' approfondita. Data la
stretta corrispondenza di questi con il codice java, il grado di dettaglio
di questi diagrammi e' superiore a quello dei diagrammi prodotti
con RationalRose
Il
rettangolino in alto a sinistra, visibile ad esempio sulla classe CashSaleDetail,
identifica gli oggetti che presentano un'interfaccia di programmazione
conforme agli standard JavaBeans e EJB (ad esempio la presenza di metodi
setX() e getX()).
La
scritta in alto a destra, visibile nella classeInsuffPaymentException,
indica la superclasse.
La
segnatura racchiusa tra i simboli << e >> rappresenta lo stereotipo:
TogetherJ associa agli stereotipi piu' usati dei colori, secondo le convenzioni
di Peter Coad (vedere bibliografia). Ovviamente e' possibile definire nuovi
stereotipi o modificare quelli esistenti.
Sotto
il nome c'e' l'elenco degli Attributi, seguono le Operazioni, le
Classi Interne e infine le proprieta' (i metodi getX() a cui vengono rimossi
i prefissi).
E'
possibile nascondere i dettagli su ogni singola classe del diagramma, in
modo da semplificarne la rappresentazione: la classe ProductPrice, ad esempio,
non mostra l'elenco degli attributi.
Ogni
elemento del diagramma e' attivo: clickando sopra la dichiarazione di un
metodo sul diagramma, la finestra dell'editor mostra immediatamente il
codice corrispondente. E' possibile aggiungere e togliere metodi, cambiarne
il nome o l'ordine, tagliare e incollare metodi ed attributi da una classe
all'altra: diagrammi e codice vengono sincronizzati dopo ogni modifica.
Documentazione
Automatica
Un'ultima
straordinaria caratteristica di TogetherJ e' la possibilita' di generare
una completa documentazione HTML del progetto, che comprende il package
tree, tutti i diagrammi e la classica javadoc, in una collezione di pagine
in cui ogni elemento e' attivo e genera rimandi agli altri. Ecco ad esempio
il link <<aggiungere link a MPDoc\index.html>> alla documentazione
di MiniPad.
Punti Deboli
Dopo
tante lodi, credo sia opportuno riferire i punti deboli riscontrati dai
validi professionisti a cui ho richiesto un'impressione d'uso.
Il
primo appunto rigurarda le prestazioni, un problema molto sentito da chi
non dispone di un hardware aggiornato. Ho individuato alcuni "trucchi"
<<aggiungere link a EppurSiMuove>> che permettono di risolvere in
parte questo problema.
Molti
utenti hanno lamentato invece una certa complessita' dell'interfaccia grafica,
ricca di bordini e tabbed pane, che rende quasi indispensabile l'uso di
un monitor 17" con una risoluzione di almeno 1024*768.
A
livello d'uso, capita che i diagrammi di classe risultino eccessivamente
dettagliati,
e
quindi illeggibili. TogetherJ mette a disposizione alcune funzionalita'
che aiutano a ridurre la complessita' dei diagrammi.
Un'opzione
di cui si avverte la mancanza e' quella di permettere la suddivisione degli
strumenti di lavoro su finestre differenti, in modo da poter lavorare comodamente
su due monitor, con il codice su uno e i diagrammi sull'altro.
Il
limitato supporto del Drag & Drop rende macchinosa la realizzazione
di diagrammi che mettono in relazione classi provenienti da package diversi.
Ma
l'aspetto piu' discusso e' proprio il Simultaneous Round Trip Engineering,
che i puristi dell'UML criticano perche' spinge il progettista a pensare
al programma in termini implementativi fin dalle prime fasi del progetto.
Queste
osservazioni non riescono comunque a mettere in ombra le straordinarie
possibilita' di questo programma, che invito a provare senza indugio.
Dove trovare TogetherJ
Potete
scaricare al sito www.togethersoft.com una copia gratuita di Together
Whiteboard, una versione ridotta ma senza limiti di tempo, o una versione
completa di TogetherJ in versione "evaluation" (e' possibile richiedere
una licenza gratuita per uso non commerciale del programma).
Conclusioni
ToghetherJ
e' uno programma innovativo, che mette a disposizione del progettista alcuni
strumenti straordinari.
Essendo
scritto in Java, libera l'utente dal vincolo di piattaforma, poiche' funziona
indifferentemente su Windows, su Linux o su Solaris. L'aderenza alle alle
piu' recenti specifiche UML ne fa uno strumento utile anche nel caso si
desideri sviluppare un progetto in un linguaggio non direttamente supportato
(Java e C++), o che addirittura si voglia relizzare un progetto non informatico.
Per
chi fosse interessato a comprendere come possa funzionare un simile straordinario
meccanismo, ho raccolto qui <<aggiungere link a ComeFunziona>> alcune
ipotesi sul funzionamento del Simultaneous Round Trip Engineering.
Bibliografia
-
"UML Distilled"
second edition Martin Fowler ADDISON-WESLEY
-
"Java
Modeling In Color With UML: Enterprise components and Process " Peter Coad,
Eric Lefebvre, Jeff De Luca - Ed. Prentice Hall
-
"Ten Golden
Rules For Financial Success - Riches I've Gathered from Legendary Mutual
Fund Manager Sir John M. Templeton" di Gary Moore Ed. Harper Collins Zondervan
Appendice 1: "Come funziona il Simultaneous
Round Trip Engineering"
La
sorprendente prerogativa di TogetherJ merita di essere approfondita.
La
mia ipotesi e' che i progettisti di TogetherJ abbiano scelto di memorizzare
una parte dei Metadati necessari a tracciare i diagrammi direttamente nei
sorgenti.
Il
seguente sorgente
public
class Class1
{}
public
class Class2 extends Class1
{
private Class3 lnkClass3;
private String name;
public String getName()
{
return name;
}
}
public
class Class3
{}
fornisce
informazioni sufficienti a tracciare il seguente diagramma
Le
uniche informazioni non presenti nel codice sono quelle topologiche come:
-
le coordinate
dei disegnini
-
l'andamento
delle frecce
Per
ogni diagramma creato, TJ genera un apposito file di testo che, ad un'occhiata
superficiale, contiene proprio questo genere di descrizione:
[......]
<oigroup:<oiref:java#Class#TextEditor:oiref>=512,133,67,59,1:oigroup>
<oigroup:<oiref:java#Class#Diagramma:oiref>=155,125,121,66,1:oigroup>
<oigroup:<oiref:java#Class#CodiceClasse:oiref>=499,266,99,117,1:oigroup>
[....]
Per
descrivere la "magia" del round-trip-engineering credo torni utile fare
riferimento al modello Model Control View utilizzato nel package Swing:
abbiamo un'oggetto che contiene una descrizione astratta del diagramma.
Una parte delle informazioni (attributi, operazioni, ereditarieta') viene
conservata direttamente in una collezione di files sorgente. L'utente puo'
modificare queste informazioni in due modi:
-
agendo
sui sorgenti con un TextEditor
-
agendo
sui diagrammi con il Modeler UML
In
entrambi i casi, il contenuto della rappresentazione astratta cambia, e
immediatamente viene inviata una notifica ad un osservatore, che aggiorna
le due viste in modo da sincronizzarle con il modello astratto.
Appendice 2: Eppur
si muove!
Un
aspetto curioso di TogetherJ e' che si tratta di un programma scritto completamente
in Java. La notizia sorprendente e' che, malgrado questo, mostra delle
prestazioni assolutamente rispettabili.
Dal
momento che questo programma che fa un uso intensivo di grafica e di Input/Output
su disco (ogni modifica richiede la scansione e la scrittura di almeno
due files), la configurazione minima consigliata e' Pentium II 250 MHZ
con 128MB di ram)
Ho
eseguito le prove su una configurazione considerata sub-ottima (Pentium
166 MMX con 64MB di ram) ottenendo comunque prestazioni accettabili: una
grossa parte del merito va alla VM di Microsoft (jview) che continua ad
essere la miglior JVM in circolazione. Un test con il runtime Kestrel di
sun (disponibile con il JDK1.3) ha rivelato delle prestazioni inferiori:
credo che la causa stia nel fatto che nel codice grafico, in cui ogni singolo
controllo viene attivato con una frequenza piuttosto bassa (un paio di
volte al minuto al massimo), l'ottimizzazione Hot-Spot porta pochi vantaggi.
Un'altro
"trucco" e' quello di ridurre i colori a 256 e disattivare le animazioni
di Windows (ad esempio con Tweak UI): lo svantaggio e' quasi inavvertibile,
mentre e' notevole il guadagno in termini di prestazioni.
Se
volete testare jview con qualche vostro programma, potete scaricarne una
copia (6MB) al sito http://www.togethersoft.com/downloads/index.htm
Per
eseguire i programmi piu' recenti c'e' bisogno del package swingall.jar:
lo trovate al sito della Sun, dentro la distribuzione di Swing1.1.1 per
il JDK 1.1
http://www.java.sun.com/products/jfc/download.html
la
sintassi della riga di comando e'
jview
/cp swingall.jar miaClasse
nell'ipotesi
che il package swingall.jar e la classe miaClasse.class si trovino nella
directory corrente.
L'unico
limite all'uso di jview e' che Microsoft ne ha abbandonato l'aggiornamento
(in conseguenza della causa in corso con la Sun), per cui le API sono conformi
alle specifiche del JDK 1.1 e non hanno recepito alcune modifiche introdotte
con il JDK 1.2.
|