Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

One View or Many?

DZone's Guide to

One View or Many?

· DevOps Zone ·
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

In Diagramming Spring MVC webapps, I presented an approach that allows you to create a fairly comprehensive model of a software system in code. It starts with you creating a simple base model that includes software systems, people and containers. With this in place, all of the components can then be automatically populated into the model via a scan of the compiled Java code. This is all based upon Software architecture as code.

Once you have a model to work with, it's relatively straightforward to visualise it via a number of views. In the Spring PetClinic example, three separate views (one each of a system context, containers and components view) are sufficient to show everything. With larger software systems, however, this isn't the case.

As an example, here's what a single component diagram for the web application of my techtribes.je system looks like.

A mess

Yup, it's a mess. The components around the left, top and right edges are Spring MVC controllers, while those in the centre are the core components. There are clearly three hotspots here - the LoggingComponent, ActivityComponent and ContentSourceComponent. The reason for the first should be obvious, in that almost all components use the LoggingComponent. The latter two are used by all controllers, simply because some common information is displayed on the header of all pages on the website. I don't mind excluding the LoggingComponent from the view, but I'd quite like to keep the other two. That aside, even excluding the ActivityComponent and ContentSourceComponent doesn't actually solve the problem here. The resulting diagram is still a mess because it's showing far too much information. Instead, another approach is needed.

With this in mind, what I've done instead is use a programmatic approach to create a number of views for the techtribes.je web application, one per Spring MVC controller. The code looks like this.

private static void createComponentViewsForWebApplication(Model model) {
    SoftwareSystem techTribes = model.getSoftwareSystemWithName("techtribes.je");
    Container contentUpdater = techTribes.getContainerWithName("Content Updater");
    Container webApplication = techTribes.getContainerWithName("Web Application");
    // create one component view per Spring controller
    Set<Component> controllers = webApplication.getComponents().stream().filter(c -> c.getTechnology().equals("Spring Controller")).collect(Collectors.toSet());
    for (Component controller : controllers) {
        ComponentView view = model.createComponentView(techTribes, webApplication);
        view.setDescription(controller.getName());
        view.addAllSoftwareSystems();
        view.addAllContainers();
        view.remove(contentUpdater);
        view.addAllComponents();
        view.remove(webApplication.getComponentWithName("LoggingComponent"));
        view.removeElementsThatCantBeReachedFrom(controller);
        view.addAllPeople();
        view.removeElementsWithNoRelationships();
    }
}
The result is a larger number of simple diagrams, but I think that the trade-off is worth it. It's a much better way to navigate a large model.

Not so much of a mess

And here's an example component diagram that focusses on a single Spring MVC controller.

Not so much of a mess

The JSON representing the techtribes.je model can be found on GitHub and you can copy-paste it into my (still in-progress) diagramming tool if you'd like to explore the model yourself. I'm still experimenting with much of this but I really like the opportunities provided by having the software architecture model in code. This really is "software architecture for developers". :-)

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}