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 è 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 funzionalità, definita simultaneous round-trip engineering, che rappresenta una grande novità nel panorama dei Modeler UML.

Diagrammi di Classe e Simultaneous Round-Trip Engineering

Un progetto sviluppato in UML ha la sua espressione più 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" 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 funzionalità, 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 è la possibilità 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), è possibile aprire più di un progetto sullo stesso insieme di classi. Se due o più 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 possibilità 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, è 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 può 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, potrà navigare liberamente nel package UserInterface, studiarne i diagrammi ed utilizzarne le classi, ma non potrà in alcun modo modificarne la struttura o il codice.

Pattern

Un aspetto che meriterebbe di essere approfondito in un articolo a parte è la possibilità di utilizzare pattern standard, o di svilupparne di nuovi. TogehterJ comprende una collezione dei pattern più 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 provvederà a generare le classi che compongono il pattern con gli opportuni collegamenti.

Personalizzazione dell'ambiente

Ogni aspetto del programma è 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 possibilità 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 è 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 è possibile vedere come vengono organizzati i progetti in TogetherJ. Un progetto è composto da un albero di packages, con un'organizzazione gerarchica che può 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 è 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 già detto, se i package si trovano in rete su un file server a cui accede più di un utente per volta, le modifiche operate da un membro del team saranno visibili immediatamente anche agli altri.

È 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 risolverà 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. È 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 più approfondita. Data la stretta corrispondenza di questi con il codice java, il grado di dettaglio di questi diagrammi è 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 più usati dei colori, secondo le convenzioni di Peter Coad (vedere bibliografia). Ovviamente è possibile definire nuovi stereotipi o modificare quelli esistenti.

La segnatura racchiusa tra i simboli << e >> rappresenta lo stereotipo: TogetherJ associa agli stereotipi più usati dei colori, secondo le convenzioni di Peter Coad (vedere bibliografia). Ovviamente è possibile definire nuovi stereotipi o modificare quelli esistenti.

Sotto il nome c'è l'elenco degli Attributi, seguono le Operazioni, le Classi Interne e infine le proprietà (i metodi getX() a cui vengono rimossi i prefissi).

È 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 è attivo: clickando sopra la dichiarazione di un metodo sul diagramma, la finestra dell'editor mostra immediatamente il codice corrispondente. È 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 è la possibilità 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 è attivo e genera rimandi agli altri. Ecco ad esempio il link 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 riguarda le prestazioni, un problema molto sentito da chi non dispone di un hardware aggiornato. Ho individuato alcuni "trucchi" che permettono di risolvere in parte questo problema.

Molti utenti hanno lamentato invece una certa complessità 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 funzionalità che aiutano a ridurre la complessità dei diagrammi.

Un'opzione di cui si avverte la mancanza è 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 più discusso è proprio il Simultaneous Round Trip Engineering, che i puristi dell'UML criticano perché 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 possibilità 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" (è possibile richiedere una licenza gratuita per uso non commerciale del programma).

Conclusioni

ToghetherJ è uno programma innovativo, che mette a disposizione del progettista alcuni strumenti straordinari.

Essendo scritto in Java, libera l'utente dal vincolo di piattaforma, poiché funziona indifferentemente su Windows, su Linux o su Solaris. L'aderenza alle alle più 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 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 è 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, ereditarietà) viene conservata direttamente in una collezione di files sorgente. L'utente può 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 è che si tratta di un programma scritto completamente in Java. La notizia sorprendente è 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 è 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" è quello di ridurre i colori a 256 e disattivare le animazioni di Windows (ad esempio con Tweak UI): lo svantaggio è quasi inavvertibile, mentre è 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 più recenti c'è 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 è:

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 è 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.