2010-09-29 7 views
8

Abbiamo una base di codice Java che è diventata troppo grande per un singolo JAR monolitico (più di 5000 classi). Uno dei compiti che stiamo studiando è quanto impegno sarebbe di rompere questo singolo JAR in componenti più piccoli con dipendenze controllate tra di loro. Tuttavia, è un po 'difficile guardare una grande quantità di codice ed essere sicuri di trovare i migliori punti di separazione senza alcuna analisi.Esiste uno strumento di visualizzazione in grado di ispezionare una base di codice Java e segnalare dipendenze tra pacchetti?

Esistono buoni strumenti per ispezionare e visualizzare le dipendenze dell'interpackage? Detto questo, avremmo una serie di punti di taglio suggeriti in cui potremmo iniziare a separare il codice.

Ad esempio, nei giorni precedenti a Netbeans ed Eclipse (e ad un altro lavoro), abbiamo utilizzato TogetherJ e TogetherEnterprise. Quelli avevano la capacità di fare un'analisi del pacchetto statico e disegnare il diagramma UML. Questo tipo di comportamento sarebbe ottimale ma questa caratteristica da sola non è sufficiente per giustificare il costo.

+0

Penso che se hai bisogno di uno strumento per dirti come organizzare le tue 5000 lezioni, allora sei in più problemi di quanto questo strumento possa tirarti fuori. In bocca al lupo. – z5h

+2

@ z5h, onestamente? Perché non dovresti usare uno strumento per cercare le dipendenze? L'output di tale strumento è molto utile per guidare il lavoro di refactoring. Ricorda, questo è il tipo di cosa che ti aiuta a identificare i nodi con un debole accoppiamento reciproco. Questi nodi possono quindi diventare candidati per prodotti di costruzione consegnabili separati. Tempi di costruzione più brevi per entrambi, cambiamenti localizzati, ecc., Sono tutte motivazioni forti per questo tipo di refactoring. Se ci sono strumenti che aiutano a sottolineare "inizia da qui, questo taglio sarebbe facile", perché non dovresti usare una cosa del genere? –

+0

Stavo solo "commentando" che se sei nella fase in cui hai 5000 classi e non c'è abbastanza architettura per guidarti nella giusta direzione senza uno strumento, allora sembra una brutta situazione. Questo non è un esercizio di ottimizzazione in cui uno strumento ti dice cosa guardare dopo. Questa è * l'intera architettura della tua applicazione *, su cui dovresti gestire meglio. Se stai usando lo strumento come verifica delle idee, allora suona bene. Se sta guidando il tuo design, sembra spaventoso. Lo hai reso come se lo strumento guidasse il tuo progetto. – z5h

risposta

1

SonarJ è un ottimo strumento per farlo, ma è costoso.

Un altro ottimo strumento è XDepend, che è più economico. Per il tuo scopo, ti consiglierei questo strumento. La scelta migliore in termini di qualità/prezzo credo.

Con molte meno funzionalità, è possibile utilizzare un'analisi Sonar (Free e OpenSource) e la sua matrice di dipendenze.

0

Le classi utilizzano i pacchetti in modo normale o tutte le classi sono nello stesso pacchetto? Se il primo caso è vero, prenderei in considerazione la scrittura di uno strumento per scopi speciali per fare il primo taglio.

+0

l'architettura originale ha sistemato le cose in modo ragionevole. Tuttavia, anni di richieste dei clienti e di nuovi sviluppi hanno portato a anni di modifiche ed è ora di riconciliare tutto ciò. 5000 classi in un pacchetto sarebbero grossolane, vero? –

+0

@bob cross - sì sì. Penso che dovrei giocarci un po 'per determinare anche come procedere. –

2

Ho utilizzato stan4j per lo stesso scopo ma purtroppo l'edizione della comunità ha un limite di 500 classi. Dall'altro lato, funziona come un'estensione di eclissi.

1

JDepend è uno strumento gratuito per analizzare le dipendenze dei pacchetti .

Identifica le dipendenze circolari, che impedirebbero la rottura di questo monolito in pezzi più piccoli.

Mettiamo questo controllo delle dipendenze circolari nei nostri test di unità, per prevenirli dall'inizio.

C'è un corrispondente Eclipse plug-in.

È possibile inviare l'output a GraphViz. Tuttavia, la visualizzazione diventa meno comprensibile con il crescere del numero di pacchetti.

Ora che CodePro AnalytiX [menzionato prima da Fabian Steeg sopra] è gratuito, vale la pena dare un altro sguardo. Almeno prima dell'acquisto da parte di Google, Instantiations produceva in modo affidabile un ottimo software. Ho giocato con lui alcuni anni fa, e non ricordo reclami oltre al costo.

1

Una buona prova sarebbe quella di invertire il file jar in un diagramma di classe.Ho trovato questo tutorial che spiega come invertire il progetto composto da file jar nel diagramma delle classi UML: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html

Si sarà in grado di invertire a livello di pacchetto a vedere la relazione di pacchetto ma anche di vedere le clases da un pacchetto in relazione ad altri Pacchetti. Una volta che il progetto è stato annullato, puoi riorganizzarlo come modello e fornire questa documentazione al team di implementazione.

alt text

0

Questo è esattamente il tipo di caso d'uso costruisco degraph per.

Consente di definire le porzioni fette, ovvero gruppi di classi che appartengono insieme e visualizzarle come un nodo comprimibile. I vasetti per essere sarebbero fette che è possibile modificare fino a quando non hanno più dipendenze cicliche, a quel punto possono diventare il loro barattolo.

Ciò semplifica l'individuazione delle dipendenze tra fette che è necessario interrompere. Poiché è possibile aprire il nodo della sezione e visualizzare tutte le classi contenute, è anche facile identificare possibili refactoring (introduzione di interfacce, classi in movimento ...) per raggiungere l'obiettivo.