Architexa is a new Eclipse-based UML modeling tool that allows developers to quickly gain insight into code relationships through UML diagrams, and share what they find with others. The key to fast exploration of the code base is to provide 3 farmiliar diagram types to developers (layered, class and sequence diagram) and allow developers to build up the relationships and granularity as they explore and understanc the code base.
InfoQ recently spoke with Vineet Sinha, founder of Architexa, to find more out about the tool and how it can help developers work with ever-expanding code bases.
How does Architexa help developers where other UML tools are lacking?
We are focusing on coding needs as opposed to design needs. We therefore want to allow developers to easily understand code, and help them in tasks related to that understanding - in documenting what they have understood and in easily discussing those important code concepts with other developers that they are working on.
Layered diagrams are a powerful way to initially explore a code base. Could you explain them to our readers a little? Did the idea come from existing work, or did you evolve the concept and how?
Layered Diagrams in Architexa try to create the closest possible estimation to a Layered Architectural Diagram given your current codebase. We noticed that most Layered Architectural Diagrams are the main form of high-level diagrams used by teams on a project - and that they are often not easy to find on many codebases. Given that having such diagrams can help developers find parts of the codebase that they are most interested in, we wanted to provide a quick version of such diagrams for developers needs.
Architexa builds the Layered Architectural Diagrams by analyzing your code and trying to show modules, in such a way that a module is shown higher in a diagram if it depends on another module. Beyond this, we need to make guesses - modules are basically created by default based on the folder structure of a codebase. Further, most codebases often have cycles, and we have added sophisticated algorithms to work with such cycles but still provide effective layered diagrams.
Most of the tool suite was experimented and built during my PhD at MIT (CSAIL). Given that we tried to be thorough in building a good tool. The primary idea came from multiple sources - I spent a significant amount of time on (i) going through software documentation on multiple projects to see common properties, (ii) analyzing current tools that provided effective code views - while these mostly were very sophisticated and required training they did have a number of strengths and we were able to see the common patterns of usages of such tools so that we could simplify with few clicks, (iii) typical tree widgets which often show alot of information neatly collapsed for a user, and (iv) a wide variety of good tools to find techniques worth adopting in our diagrams.
Once we built the first prototype, we found a number of problems. Most of our major ideas worked but we realized real world problems (code often having cycles) and we developed techniques to not only address them (by layering ignoring some code cycles), but also to make it easier for users in such situations to easily work with them (to allow users to expand based on dependencies in such cycles, and to use color highlighting to show the modules that build on, are built using, and have cycle to the current module).
Architexa allows you to start from a blank slate of knowing nothing about the code base, and explore. Have you found usage patterns that you tend to use when exploring code bases? How do you use the tool in your day-to-day development/design?
We have found a number of usage pattens, and are actively investigating these to make the tool better. But most of the usage is dependent on the users task:
- If he wants to start looking at a project (or part of a project), he typically would want a high-level view, and he would in such cases want to use a layered architectural diagram to start at the top and then double click to keep diving into the heart of such code.
- If he wants to understand the core of a project (or sub project), he typically would want to see how multiple classes interact and thus would want to see multiple relationships (inheritance, method calls, field accesses, etc) and would typically like to use a class diagram.
- If he wants to understand an import use case, he would want to see the control flow, and would benefit from a sequence diagram.
Is there a way to compare an existing diagram with a code base that has changed?
The use of diagrams when a code base has changes has a number of interesting possibilities. We support two use cases:
- When a user creates a diagram and then changes the codebase - if he opens the diagram again a red error marker is shown on missing classes / relationships.
- When a user changes the codebase and wants to create a diagram - the user can just right click on the project, go to the team menu and ask Architexa to use the changes to build a diagram instead of checking the code in. The benefit of doing this is that it can easily allow for code reviews since the generated diagram is often a good summary of the modified functionality.
We are investigating to add more support here.
Manually generating diagram is a good way to explore the code base, but being able to automatically generate them during a build (similar to JavaDoc) can portrait the evolution of a system. Is this something that Architexa can also do?
Important diagrams often span multiple classes, and each important class often spans multiple diagrams, so putting them in JavaDoc does not make sense. We instead allow users to quickly just upload diagrams to a simple wiki-like server that we have. It allows you to not only share the pictures for those that want to see the diagrams using a web browsers but also allow us to include extra information so that others users with the Architexa client can easily continue the exploration that might have been made by some other author. These diagrams represent the important concepts in a codebase, and therefore have support not only for users commenting on them, but also for embedding them in different places, and are also versioned to show the evolution of the main concepts. We are investigating to add more support here.
What languages does the tool currently support?
This release includes Java support only. We have prototypes for C++.
Can the tool help illustrate components as well as core class interactions (i.e. MVC / web framework interactions)?
Yes. The goal for the suite is to show any relationship that is either explicitly in the code (method calls, inheritance, etc) or done so at runtime (calls to interfaces or base classes). We do this by using the static relationships, but allowing users to change the diagram in any way that might be implied based on the code.
Can you share any features that didn't make that first release, but will be coming soon, that readers may be interested in?
We have a large number of features in this release. While we do have more available for release, our main goal right now is to listen to what users think about what we have done and to fill the biggest holes.
For more information, visit the Architexa website at http://www.architexa.com.