DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Introducing Degraph for Visualizing Package Dependencies

Introducing Degraph for Visualizing Package Dependencies

Jens Schauder user avatar by
Jens Schauder
·
Mar. 01, 13 · Interview
Like (0)
Save
Tweet
Share
5.74K Views

Join the DZone community and get the full member experience.

Join For Free

I wrote before that I consider packages an important tool for structuring your code. I like to have a well defined package structure, where
  • each and every package belongs to a set of slices, with a slice being either a domain module containing code dealing with a certain part of the domain (like, ‘shopping cart’, ‘fulfillment’, ‘customer’) or a technical part of the application (‘presentation’, ‘persistance’, ‘domain’)
  • all dependencies between packages and slices are free of cycles

One problem with this set of rules is: Since dependencies aren’t readily visible in the code it is hard to maintain these rules. And once they are broken it is even harder to fix them.

In one project this lead to developers packing lots of stuff in a single package, because they didn’t know where to put new stuff without creating circles. Obviously that was not what we intended with the rules. But what do you do when faced with a package containing 170 classes and the task to break it (as a first step) in a set of smaller packages void of dependency cycles?

There are tools that tell you when you have dependency cycles. Most of the time they show you the problem as a dependency structure matrix. Unfortunately it is really hard to identify a bunch of classes that you can pull out of a package in order to fix a dependency cycle. They tell you even less about which group of classes you can pull out of a package without creating new dependency cycles.

In order to fix this I created Degraph.

Degraph analyses the dependencies of a bunch of class or jar files and creates a graph representation of it. In this graph it also groups classes into packages and if you want into slices. The result is written to disc as a graphml file. This file can then be opened with yed, a free graph editor with strong layout capabilities.

The result looks like the following image (click for a larger version).

selfTestBlogExample

You can see packages as boxes containing classes. If the classes contain inner classes those are contained in the boxes representing the outer classes. What is not visible in the image is that you can open and collapse the boxes representing packages or classes with inner classes. This enables you to show that part of the dependencies that you actually care about.

If this sounds interesting to you give it a try. You can download the current distribution and install it by unzipping it (you’ll need a a properly installed JRE). You can find more instructions on how to use and configure Degraph in its wiki

Degraph is obviously at a very early stage of development, but it is still useful (and fun) if you want to have a look at the structure of your class dependencies. While it shows you the dependency and allows you to identify cycles visually, so far it doesn’t identify such cycles on its own. I’m currently working on adding that ability.

Probably next is the option to integrate Degraph in JUnit (or other) automated tests.

Beyond that I have tons of ideas (definition and test of allowed/disallowed dependencies, creation of dot files, interactive specialized ui, identification of dependencies to break, integration of spring file analysis ..) but this will obviously take some time. In the mean time: If you find a bug, have a problem or an idea for improvement, leave a comment or open an issue.

 

Dependency

Published at DZone with permission of Jens Schauder, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Apache Kafka Introduction, Installation, and Implementation Using .NET Core 6
  • The Real Democratization of AI, and Why It Has to Be Closely Monitored
  • Implementing Infinite Scroll in jOOQ
  • Connecting Your Devs' Work to the Business

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: