I am always baffled by the relationships in systems. When I am pulled into a project I find myself spending a fair amount of time diagramming things so I can better understand these relationships. And it is usually in these diagrams that I find many of the issues I later have to correct.

Turns out that developing-first is far too common. Everyone talks a good game when it comes to documentation and clear designs prior to coding. But it is far too easy for that part of a project to be the part that people think is “compress-able”. I’m guilty here too. Sometimes it actually helps to play in the code a bit to get a solid design. But I think that’s likely the excuse I use.

js_diagram_01I set out to fix that a little here. I decided that writing a code-injection system for a SOOJS project could result in deeply meaningful relationship diagrams that could indicate not just instantiation relationships, but also observer information.

I set out trying to create what I call “Waterfall Diagrams” where the relationships are both orderly but also hierarchical. I wanted it to be able to feed off of any file with the right format as well as off the active source code. This way I could store off version of the system at any time but also use the viewer to see the changes as I was implementing them.

While I am only at the first release of such a system, it is truly meaningful to see how a live system is all stitched together. This little auto-diagramming tool gives me a much better feel for the “corner” of a system I currently work in.

class_viewThe other element that is critical here is some way to see the internals of the class itself. A “class browser” if you will. Something that I can see the relationships and observers all in one quick place. It also shows me any attributes, css styles, inputs and outputs from a given class. And all of it linked together so I can walk up and down the relationships by clicking any item.