Approach

Technical Dependencies

Ariadne is strongly-based on the concept of dependencies. Dependencies among pieces of code exist because components, inevitably, make use of services provided by other components. A data structure containing all the dependency relationships of a program is called a call-graph, because it contains information about which components call the services provided by other components in the system. Ariadne supports the creation and visualization of call-graphs from Java programs. Because Java is an object-oriented language, the call-graph describes the relationship between methods being invoked by other methods in the context of their respective classes and packages.

Social Dependencies

By describing dependencies in the source-code, a call-graph potentially describes dependencies among software developers responsible for those software components. For example, where component "A" depends on component "B", assuming that "A" is being developed by developer a and "B" is being implemented by developer b, since "A" depends on "B", we can infer that developer a depends on developer b. Hence, to be able to describe these social dependencies, it is necessary to populate the call-graph with social information, i.e., information about which software developer wrote which part of the code.

Update: New Visualizations

Our new visualization interface allows users to easily reveal information about the technical dependency information, meaning no information is lost. The layout of this reduced dependency graph keeps important graph characteristics and benefits from a consistent layout that helps highlight information required to reason about coordination needs.

To take advantage of available screen real estate, Ariadne lays out dependency information in a type of table-based fashion placing the most numerous data items along the longest screen dimension. Called code units occupy the x-axis and authors occupy the y-axis, with both ordered alphabetically by default. Users can reorder the axes based upon queries against all the data and its associated meta-data. We draw connections from a dependent author to the code unit they are dependent upon and back to the author responsible for that code unit and repeat for each set of socio-technical dependency information in the project. The color of each line (or dependency) denotes the directionality of the dependency and shares its color with the originating (dependent) author.

Viewing dependency information using this hybrid table- and graph-based approach offers pattern recognition capabilities, easy filtering, and comparisons. An unfiltered overview of the dependency information allows us to show the state of dependencies for an entire project at once. From this perspective it is possible to recognize patterns in the way developers call other developers code, prominent code modules, and prominent authors even for a specific area of the code.

Filtering the overview by artifact reveals connections only from authors using that artifact. Managers and developers can focus on artifacts at different granularities that may be undergoing many changes in order to determine developers' progress. Focusing on an artifact may allow managers and developers to locate other developers affecting or affected by changes to that artifact.

Using an additive approach, we can compare the calls on code units made by one author with those made by another author. The user can click on authors' names to reveal only their dependency information. Ariadne's visualization technique preserves the ease of identifying connections between authors found in simple social network graphs of developers. Looking at only the y-axis, users can readily determine the inbound and outbound connections between a project's developers. The presence of a color corresponding to an author's name indicates an outbound dependency, while the presence of other authors' colors indicates an inbound socio-technical dependency from those other authors. While Ariadne's visualization makes a significant departure from a more traditional graph-based approach, it does not eliminate the advantages of that method of data display.

Authorship information about each node of the call-graph can be extracted from configuration management repository. Currently, Ariadne supports CVS repositories. By Combining information from the call-graph with authorship information from the CM repository can then create a "social call-graph", that describes which software developers depend on which other software developers for a given piece of code. A directed edge from package A to B indicates a dependency from A to B. Directed edges between authors and packages indicate authorship information. Every node of the call-graph might have different options for the associated authorship information: for example, in a company, one might decide to use information about the last person who committed changes in the file because the last committer is sometimes considered an expert on it, in another company, ownership architectures could be used since it expresses the relationship between developers and source code.

Temporal Analysis of Dependencies

One of Ariadne's features is the ability to download specific releases of a software project from an arbitrary point in time. By using this feature, we created the following four graphs from four distinct releases of the Megamek project. Megamek is an open-source project freely available in the Internet. The graphs convey an idea of how developers' roles in Megamek have changed over time.

As the first graph illustrates, early in the development of Megamek, author "spiker" was the most depended upon. However, the latest release tells us that while author "spiker" remains central to the project, more and more developers are making calls to modules of code that author "staindedg" has implemented. As a result, we expect that the remaining authors are frequently coordinating their work with "spiker" and "stainedg," whose interfaces are heavily depended upon.

 

Ariadne's Users

We envision two types of users for Ariadne:

Software developers who would use it to identify colleagues with whom they need to interact, that need to be informed about changes that are going to impact them, or with similar interests.

Project managers or researchers interested in understanding the interplay between the changes in the architecture of the software and its social impact. For example, by analyzing the density of a social network or by identifying bridges in this network one can understand the key role played by some software developers in the coordination process or better understand their coordination and communication needs.