ArchJava

The paper "ArchJava: Connecting Software Architecture to Implementation" addresses the problem of architecture and implementation happening independently of each other. A problem with this duplicity is that the implementation usually ends up diverging from the architecture with backdoor communication paths and "hacks" that are not captured in the architectural diagrams. In fact in many cases I believe such backdoors are intentionally kept out of diagrams and descriptions to prevent them from messing up the otherwise beautiful illusion. To fix this the developers either have to update the architecture diagrams (which would probably complicate them) or change the implementation to conform to the architecture description.

The paper present ArchJava which is a set of extensions to the Java programming language that captures the architecture through components and communication paths. As our previous readings have tried to tell us (BA Ch. 1, 4+1, Boxology) these are far from all the aspects of architecture, but they are probably among the most important ones. We could see this quite clearly in the wreck that was the messy metropolis (BA Ch. 2). Components in ArchJava are a special type of classes that can contain subcomponents, thus forming a component hierarchy. Communication paths are "ports" that can be connected to other components. These ports consist of required and provided methods that forms a contract that all components we want to connect to them must conform to. In fact they rather remind me of two-way Qt/boost signal-slots, which allows developers to connect conforming signals and slots from any two classes together. Signal/slots in these C++ libraries are really useful, but have been around for a long time. Furthermore ArchJava disallows all non-port method calls to components that are not a sub-component of the caller and guarantee that this restriction is enforced.

An important feature of ArchJava is that it is implemented directly in the Java language as a set of extensions. The developers are thus relieved from having to maintain two duplicate architectural descriptions; the explicit description on paper (or in a separate ADL) and the implicit one in the source code. In addition to less maintenance is the practical consideration that everything that is duplicated will diverge and cause confusion, misunderstandings and sometimes havoc (I've always wanted to use that word in an academic setting!).

In addition to avoiding duplications having the architecture description explicit in the source code allows the ArchJava compiler to guarantee that there are no hidden back doors (with the rather big exception of shared data). This guarantee is rather useful as one can be sure that the architecture one discusses is the one that actually exist, even though it is probably not the same as one started out with. I think it could also be useful in allowing developers to refactor the architecture with more confidence the same same way that unit tests and interface contracts do.

The authors of the paper spent considerable paper-space on a case study of a small to medium sized application. Their intent was on demonstrating how ArchJava could be added to an existing application to force the architecture to be explicit, but I got the feeling most of the paragraphs were about refactorings that were based more on the knowledge of more experienced Java developers. That being said they did manage to convince me of the benefits in being sure the architecture you think you have is the one you actually have, especially as the size of the project increases into the hundreds of thousands of lines.

Referring to the questions from Professor Johnson, like Jason Danielson (I really liked the video blog by the way), I do not think ArchJava would have helped the team making memories much in the initial development. The system was created by a team of seemingly skilled developers that appeared to be highly motivated and set on making a great system with a great architecture. In a sense they had solved this problem through process, skills, gelling and caring and this is far more potent than any set of language extensions.

However, the part of the making memories saga that we were told about was only the initial development which is a fraction of the whole story. The system they made will need to be maintained for many more years and it is my experience that architectural rot has a higher tendency to set in in this phase. The discipline that ArchJava enforces would probably be far more useful ten years down the line when all the original developers and all the excitement of creating a new great system are long gone.