System attraction: depicting the emergent nature of software architecture

Architecture is an emergent property, and like any respectable emergent property it is hard to communicate.

Visualization is the best medium I know for this purpose. However, I could not find a visualization that serves the purpose properly. There are many ways to visualize a software system, and there are many tools that do it. A common way of representing software systems is by displaying it as a graph. The graph is typically laid out to exhibit a certain desired structure such as inheritance or containment. These are great tools when looking at those aspects.

However, in my experiment, I wanted to show structure as an emerging property rather than impose a certain view on the system. To this end, I asked myself "where does code want to be?". Extrapolating object-oriented principles, I wanted to let the code go both where it is needed and next to what it needs.

Designing a visualization with this purpose in mind turned out to be rather straightforward. I simply displayed all classes, methods and attributes as nodes and inheritance, containment, invocations and accesses as edges, and I used a force based layout to arrange the graph. The result is a visualization as can be seen below. I named it the System Attraction and the implementation can be found in Moose.

What can you see here?

Classes are black. Methods are red. Attributes are blue. Method containment, attribute containment, and class inheritance are gray. Invocations are red. And accesses are blue.

While things might appear random at first, at a deeper look there is a certain order that emerges from all the entangling. You might notice that colors are not uniformly distributed throughout the space. At the center, there appears to be much agglomeration of red surrounded by blue. This seems to indicate that there exist a consolidated behavior at the center of the system. There are groups of black spots (i.e., classes) that want to be close together. Also, the blue backbone on the bottom right seems to indicate a significant aggregation of related data.

System-attraction-argouml.png

To get a better feeling for how systems can be different, let's compare the above example with the one below. The two systems are comparable in size, yet, they exhibit much different patterns. The second system is much stronger on state. In fact, it looks as if it's the data that drives the system, and methods are just adjacent. Furthermore, while the first system seems to have at least one strong agglomeration of behavior, the second one has multiple small ones.

System-attraction-enterprise.png

These picture exhibit macro emergent patterns that are determined by forces in the code. For example, a method is indeed attached to its classes, but if there are many other external interactions, the method will tend to go away from its class. The visualization lets the sum of all these forces decide the shape of the system.

Few visualizations offer a meaningful outcome both when applied in the large and when used in the small. System Attraction is an experiment that aims to offer value at several granularity levels.

For example, look at the picture below showing a visualization applied on one single class.

System-attraction-single-TabResults.png

This class has essentially an equal amount of attributes and methods. What's more, one method seems to be particularly lonely. It's as if, it does not want to be a method at all. Guess what. Here is the code:

public void actionPerformed(ActionEvent ae) {
   // ignored
}

Let's compare this class with another one. This class has a more classic structure with multiple methods and few attributes. The methods seem to collaborate with one another and the attribute usage is reasonably distributed throughout the methods. It looks like a tidy class with proper structure in place.

System-attraction-single-NotationProvider.png

If you investigate the class through the lenses of a classic visualization, such as a class blueprint, you can indeed see a rather clean structure.

Blueprint-NotationProvider.png

Let's add to our scene a collaborator class next to the original one.

System-attraction-single-NotationProvider-1-provider.png

The class changes shape a bit. Let's add another one. The shape changes a bit more.

System-attraction-single-NotationProvider-2-providers.png

Now, let's see what happens when we visualize this class together with all its provider and client classes.

System-attraction-NotationProvider-clients-providers-no-highlight.png

Ahh, where is our class now? The tiny tidy shape cannot be seen anymore. Let us highlight our class.

System-attraction-NotationProvider-clients-providers-highlight.png

When placed next to its collaborators, the class changes shape dramatically. Regularity is secondary to distinct interests. For example, a group of four methods wants to be the center of everyone's attention, while some other methods want to mingle with other classes in the north.

Software architecture is an emergent property. Clearly, this shape of the system does not reflect any traditional view on architecture. There are no model-view-controller or layer patterns to be found. Nevertheless, patters do emerge. And what is architecture if not the structure that defines the system?

Indeed, when we look at the code only through a diagram that imposes a predefined structure, such as a UML diagram, we will tend to see only the defined regularities. These visualizations are not bad. They have their place precisely when it is those regularities we want to reason about. But, only being exposed to rigid shapes encourages a type of thinking that leads to the illusion of complete controllability.

System Attraction is an exercise that offers a radically different view on a software system. By not imposing a specific structure, it enables hidden patterns to emerge.

A common point of view says that architecture is only to be seen in the large. Yet, the forces embedded in the code influence the shape of the system in the small as well. Even if it is more comfortable to see a class as having a regular and controllable shape, when seen in its usage environment, the shape can morph in unexpected ways.

In our exercise we only looked at simple code elements such as classes and methods and standard interactions such as inheritance and invocations. We completely ignored technology specific details. And we completely ignored the social behavior around the software system. Even so, the experiment shows that software architecture is driven by interaction and it never is single minded. Only by acknowledging the underlying forces in a software system can you handle them appropriately.

Is this the right view for acting on a software system? Likely not. But, the goal of the exercise is to help communicate the emergent nature of software architecture. Why is it important to communicate it? Because we need to move from a controlling model towards a distributed one in which everyone is empowered to contribute.

Posted by Tudor Girba at 3 October 2013, 11:22 pm with tags moose, assessment, daily link
|