是否有可视化工具可以检查 Java 代码库并报告包间依赖关系？
我们的 Java 代码库已经变得太大，无法容纳单个整体 JAR（超过 5000 个类）。我们正在研究的任务之一是需要花费多少精力才能将这个单一的 JAR 分解为更小的组件，并且它们之间的依赖关系受到控制。然而，在不进行分析的情况下查看一大堆代码并确保找到最佳分离点有点困难。
是否有好的工具来检查和可视化包间依赖关系？鉴于这些，我们将有一组建议的切入点，我们可以在其中开始分离代码。
举个例子，在 Netbeans 和 Eclipse 出现之前（并且在不同的工作中），我们使用 TogetherJ 和 TogetherEnterprise。他们有能力进行静态包分析并绘制 UML 图。这种行为将是最佳的，但仅此功能不足以证明成本合理。
We have a Java code base that has grown to be too big for a single monolithic JAR (more than 5000 classes). One of the tasks that we are investigating is how much effort would it be to break this single JAR into smaller components with controlled dependencies between them. However, it's somewhat hard to look at a big bag of code and be sure that you are finding the best points of separation without some analysis.
Are there good tools to inspect and visualize the interpackage dependencies? Given those, we would have a set of suggested cut points where we could begin separating code.
As an example, in the days before Netbeans and Eclipse (and at a different job), we used TogetherJ and TogetherEnterprise. Those had the ability to do a static package analysis and draw the UML diagram. That sort of behavior would be optimal but that feature alone is not sufficient to justify the cost.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我最近发现了 CodePro AnalytiX，以前来自 Instantiations，现在可以从 Google 免费获得：
https://developers.google.com/java-dev -tools / codepro / doc /功能/依赖项/依赖项
I have recently discovered CodePro AnalytiX, formerly from Instantiations, now available for free from Google:
https://developers.google.com/java-dev-tools/codepro/doc/features/dependencies/dependencies
Intellij IDEA有一个：
（来源：jetbrains.com）
Intellij IDEA has one:
(source: jetbrains.com)
我使用 stan4j 来达到同样的目的，但不幸的是社区版有 500 个类的限制。另一方面，它作为 Eclipse 扩展运行。
I used stan4j for the same purpose but unfortunately the community edition has a 500 classes limit. On the other side, it works as an eclipse extension.
JDepend 是一个用于分析包依赖关系的免费工具。
它识别循环依赖关系，这将阻碍将这个整体分解成更小的部分。
我们将对循环依赖项的检查放入单元测试中，以从一开始就防止它们发生。
有一个相应的 Eclipse 插件。
您可以将输出发送到 GraphViz。然而，随着包数量的增加，可视化变得越来越难以理解。
现在 CodePro AnalytiX [上面由 Fabian Steeg 首先提到的] 是免费的，值得再看看。至少在被 Google 收购之前，Instantiations 可靠地生产了出色的软件。几年前我玩过它，除了成本之外没有任何抱怨。
JDepend is a free tool for analyzing package dependencies.
It identifies circular dependencies, which would impede breaking this monolith into smaller pieces.
We put this check for circular dependencies into our unit tests, to prevent them from the start.
There's a corresponding Eclipse plug-in.
You can send the output to GraphViz. However, the visualization becomes less understandable as the number of packages grows.
Now that CodePro AnalytiX [mentioned first by Fabian Steeg above] is free, it's worth another look. At least prior to purchase by Google, Instantiations reliably produced great software. I played with it some years back, and recall no complaints other than cost.
一个好的尝试是将 jar 文件反转为类图。我发现这个教程解释了如何将由 jar 文件组成的项目反转为 UML 类图： http: //www.ejb3.org/jar_file_reverse/jar_file_reverse.html
您将能够在包级别进行反转，查看包关系，而且还可以查看一个包中与其他包相关的类。一旦项目被逆转，您就可以将其重新组织为模型，并将此文档提供给实施团队。
A good try would be to reverse your jar file into a class diagram. I have found this tutorial which explain how to reverse project composed by jar files into UML class diagram: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html
You will be able to reverse at package level at see package relation but also to see clases from one package having relation to other packages. Once the project has been reversed you can reorganize it as a model and give this documentation to the implementation team.
SonarJ 是一个很好的工具，但它很昂贵。
另一个非常好的工具是 XDepend，它更便宜。出于您的目的，我会推荐您这个工具。我认为就质量/价格而言最好的选择。
功能少得多，您可以使用 Sonar （免费和开源）分析及其依赖关系矩阵。
SonarJ is a good tool to do that, but it is expensive.
Another very good tool is XDepend, which is cheaper. For your purpose, I would recommand you this tool. The best choice in terms of quality/price I think.
With much less functionalities, you can use a Sonar (Free and OpenSource) analysis and its dependencies matrix.
这些类是否以正常方式使用包，或者所有类都在同一个包中？如果第一种情况属实，我会考虑编写一个专用工具来进行第一次剪切。
Do the classes use packages in a normal fashion or are all the classes in the same package? If the first case is true, I'd consider writing a special-purpose tool to do the first cut.
这正是我构建 degraph 的用例。
它允许您定义切片，即属于在一起的一组类，并将它们可视化为一个可折叠节点。您的 jar 将成为您可以调整的切片，直到它们不再具有任何循环依赖项，此时它们可以成为自己的 jar。
这使得您可以轻松发现需要打破的切片之间的依赖关系。由于您可以打开切片节点并查看所有包含的类，因此还可以轻松识别可能的重构（引入接口、移动类..）以实现您的目标。
This is exactly the kind of use case I build degraph for.
It allows you to define slices, i.e. sets of classes that belong together, and visualizes them as one collapsible node. You jars to be would be slices that you can tweak until they don't have any more cyclic dependencies, at which point they can become their own jar.
This makes it easy to spot dependencies between slices that you need to break. Since you can open the slice node and see all the contained classes it makes it also easy to identify possible refactorings (introducing interfaces, moving classes ..) to achieve you goal.