MokaByte Numero  42  - Giugno 2000
TogetherJ 
Un Modeler UML al
servizio del programmatore
di 
Andrea Gini
Prova su strada di uno dei modellatori UML più famosi disponibili sul mercato
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.
 

 

Chi volesse mettersi in contatto con la redazione può farlo scrivendo a mokainfo@mokabyte.it