2010-09-29 16 views
8

Tenemos una base de código Java que ha crecido demasiado para un único JAR monolítico (más de 5000 clases). Una de las tareas que estamos investigando es cuánto esfuerzo sería dividir este único JAR en componentes más pequeños con dependencias controladas entre ellos. Sin embargo, es algo difícil mirar una gran bolsa de código y asegurarse de encontrar los mejores puntos de separación sin algún análisis.¿Existe alguna herramienta de visualización que pueda inspeccionar una base de código Java e informar dependencias entre paquetes?

¿Existen buenas herramientas para inspeccionar y visualizar las dependencias entre paquetes? Dados esos, tendremos un conjunto de puntos de corte sugeridos donde podríamos comenzar a separar el código.

Como ejemplo, en los días previos a Netbeans y Eclipse (y en un trabajo diferente), utilizamos TogetherJ y TogetherEnterprise. Esos tenían la capacidad de hacer un análisis de paquete estático y dibujar el diagrama UML. Ese tipo de comportamiento sería óptimo, pero esa característica por sí sola no es suficiente para justificar el costo.

+0

Creo que si se necesita una herramienta para decirle cómo organizar sus clases 5000, entonces usted está en más problemas de tal herramienta puede retirarse de. Buena suerte. – z5h

+2

@ z5h, ¿de verdad? ¿Por qué no usarías una herramienta para buscar dependencias? El resultado de tal herramienta es muy útil para conducir el trabajo de refactorización. Recuerde, este es el tipo de cosa que le ayuda a identificar los nodos con acoplamiento mutuo débil. Esos nodos pueden convertirse en candidatos para productos de desarrollo entregables por separado. Tiempos de construcción más cortos para ambos, cambios localizados, etc., son todas motivaciones fuertes para este tipo de refactorización. Si hay herramientas que ayuden a señalar "comienza aquí, este corte sería fácil", ¿por qué no usarías tal cosa? –

+0

Solo estaba "comentando" que si estás en la etapa en la que tienes 5000 clases y no hay suficiente arquitectura de aplicaciones para guiarte en la dirección correcta sin una herramienta, parece una situación muy mala. Este no es un ejercicio de optimización donde una herramienta te dice qué mirar a continuación. Esta es la * arquitectura completa de su aplicación *, que debería tener un mejor manejo. Si está usando la herramienta como verificación de ideas, entonces eso suena bien. Si está liderando tu diseño, eso suena aterrador. Hiciste sonar como si la herramienta liderara tu diseño. – z5h

Respuesta

1

SonarJ es una buena herramienta para hacer eso, pero es costoso.

Otra herramienta muy buena es XDepend, que es más barata. Para su propósito, le recomendaría esta herramienta. La mejor opción en términos de calidad/precio, creo.

Con muchas menos funcionalidades, puede usar un análisis Sonar (Free y OpenSource) y su matriz de dependencias.

0

¿Las clases usan paquetes de manera normal o todas las clases en el mismo paquete? Si el primer caso es cierto, consideraría escribir una herramienta especial para hacer el primer corte.

+0

la arquitectura original establece las cosas de una manera razonable. Sin embargo, años de solicitudes de clientes y nuevos desarrollos han conducido a años de ediciones y es hora de volver a unir todo eso. 5000 clases en un paquete serían brutas, ¿no? –

+0

@bob cross - sí, de hecho. Creo que tendré que jugar con eso por un tiempo para determinar incluso cómo proceder. –

2

He utilizado stan4j con el mismo propósito, pero desafortunadamente la edición de comunidad tiene un límite de 500 clases. Por otro lado, funciona como una extensión de eclipse.

1

JDepend es una herramienta gratuita de análisis de dependencias de paquetes .

Identifica las dependencias circulares, lo que impediría romper este monolito en piezas más pequeñas.

Ponemos esta comprobación para las dependencias circulares en nuestras pruebas unitarias, para evitarlas desde el principio.

Hay un Eclipse plug-in correspondiente.

Puede enviar la salida a GraphViz. Sin embargo, la visualización se vuelve menos comprensible a medida que crece la cantidad de paquetes.

Ahora que CodePro AnalytiX [mencionado por primera vez por Fabian Steeg arriba] es gratuito, vale la pena mirarlo de nuevo. Al menos antes de la compra de Google, Instantiations produjo de forma confiable un excelente software. Jugué con él hace algunos años, y no recuerdo ninguna otra queja que no sea el costo.

1

Un buen intento sería invertir el archivo jar en un diagrama de clases.Encontré este tutorial que explica cómo invertir el proyecto compuesto por archivos jar en el diagrama de clase UML: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html

Podrá revertir a nivel de paquete en la relación de paquete pero también para ver las clases de un paquete teniendo relación con otras paquetes. Una vez que se haya invertido el proyecto, puede reorganizarlo como modelo y entregar esta documentación al equipo de implementación.

alt text

0

Este es exactamente el tipo de caso de uso construyo para degraph.

Le permite definir sectores, es decir, conjuntos de clases que pertenecen juntas, y las visualiza como un nodo plegable. You jars to be sería slices que puede ajustar hasta que no tengan más dependencias cíclicas, en ese punto pueden convertirse en su propio jar.

Esto hace que sea fácil detectar las dependencias entre sectores que necesita para romper. Como puede abrir el nodo de división y ver todas las clases contenidas, también es fácil identificar posibles refactorizaciones (introducción de interfaces, clases en movimiento ...) para lograr su objetivo.

Cuestiones relacionadas