GRUMPS Documentation: 4+1 Architecture

I'll be frank: the GRUMPS time machine is not the best documented device on the planet.  I mean sure, the polyphasic stretcher itself  has 6 or 7 research paper's worth of documentation, but its stable operation is dependent upon numerous layers of control logic.  The level of algorithmic complexity required to manipulate non-deterministic particles into deterministic states resulted in a broad-reaching, patchwork base of code.  Things would look functional, and then I'd find myself opening worm holes through the building's plumbing.

I've made a few attempts at retroactive documentation, some of which were helpful for a time, but most of which are currently out of date.  Last week, I had a wonderful interview cut short by some gravitational instabilities, and I've since been working on improving the longevity of my parallel calls.  It's given me a chance to revisit some documentation, and apply some new techniques to documenting the system.

Today, rather than an interview, I'll be giving a high-level glimpse of the underlying structure of GRUMPS' software system, using one of the views described in the 4+1 architectural style.

Below is the logical blueprint for the some of the main software systems involved in cross-time communication, and their interdependency:

 This kind of view establishes some advantages and disadvantages.  It's highly oversimplified, which can be useful in designing the core structure of the system, however, it seems somewhat disorganized despite its simplicity.  In part this is the fault of the designer, and in part of the expressive language.

A good architectural language doesn't merely exist to express organization, but can help a developer impose it.  I respect that 4+1 provides a limited language for each view to keep things scoped simply, but at the same time there are expressive benefits that other languages have.

4+1 doesn't express encapsulation in an intuitive manner.  I can draw lines to represent these relationships, but intuitively, I want to box some concepts around other ones.  And I want to specify actors in a diagram that doesn't ask for them.

Admittedly, I can express architectural layers from using the Development View, but this might cluster together functionality that isn't, well... functionally related.  I want to express the concepts that I consider important, not necessarily the ones dictated by a specification.  I've certainly been guilty of mixing diagram types in the past: frankenmaps of package and object structure in one, communication diagrams built from spare sequence diagram parts.

Like in UML, 4+1 leads me to ask: should I deviate from the specification because I find it clearer, or should conform to the specification because it is representing a quality of the system I am overlooking?

Only further documentation will tell.