ArchJava

This post is based on the paper ArchJava: Connecting Software Architecture to Implementation by Jonathan Aldrich, Craig Chambers, and David Notkin [ACN]. We heard of ArchJava in my previous post on Software Architectural Primitives.

This paper stresses the importance of tying the software architecture to its implementation. Consistency between the architecture and implementation is important for analysis and reasoning. The current state of software development usually decouples the software architecture from its implementation. [ACN] argue that this is undesirable since it becomes harder to keep the architecture and implementation in sync. To emphasize their point, they introduce the term communication integrity:

A system has communication integrity if implementation components only communicate directly with the components they are connected to in the architecture.

A system with communication integrity, the authors argue, enable architectural reasoning about its implementation. Thus, they propose ArchJava, an extension to the Java programming language as a way to maintain communication integrity. ArchJava adds new language construct to support components, connections and ports.

What really surprise me is the resemblance this extension has with VHDL. VHDL is a hardware description language that uses ports, components and connections to describe electrical components in code. VHDL is meant to mimic the electrical components closely. It was hard to program in VHDL because you need to keep track of the in and out ports that each component provides. However, because of those ports, it was actually easier to ensure that our components had the right specifications.

In VHDL IDEs. there are usually tools that help you make the connection between components. You can drag a line to show that one port was connected to the other; it would then generate the code that actually did that connection for you. Apparently there is no such tool for ArchJava and the developer has to manually connect the components using code.

One of the problems I have with ArchJava is the fact that if you decide to use it somewhere in your program, you would need to use it everywhere. It is not possible to just describe one part of the system (maybe the more complicated parts) and leave the simpler parts alone. Therefore, existing programs that want to take advantage of ArchJava have to be rewritten. The paper has an example of rewriting. And while rewriting did not take a lot of time, it is not a trivial task either. This could discourage exiting projects from adapting ArchJava.

I also suspect that ArchJava makes programming more restrictive. For developers using dynamic languages, developing in static-type languages already feels very restrictive. I suspect that it would feel even more restrictive once ArchJava comes into the picture. It would require discipline to follow the those rigid requirements. This might be a good thing but it is probably hard to write a quick prototype using ArchJava.

The main advantage I see with ArchJava is that connections between modules is now explicit. This can be useful for developers when they need to do a quick review if they are actually following the specification.

In my opinion, ArchJava is not meant for everyone. If your development project requires stringent adherence to specifications, then ArchJava might be a solution. But for most projects, it is probably too restrictive.