Representation of structure

Comments (4)

Print This Post Print This Post

Email This Post Email This Post


Structure in the design of systems is usually represented by some form of schematic or block diagram.  Block diagrams describe logical relationships between design elements, without getting hung up on physical detail.  UML class diagrams and electronic schematics are examples of such abstract structural models of “things that are made out of things.”

Graph diagrams have one big trick for managing scale by collapsing compositional hierarchy into subdiagrams.  Most of the time, I don’t care how an integrated circuit works, I’m only interested in the inputs and outputs.  I’d rather treat it as a unified thing, even if the components on the inside of the thing are of the same type as the components I connect to the outside.

If our biggest scaling trick is reserved for object composition, then other hierarchical relationships may be described by color, symbolism, or layout.  Color can be tricky because of problems with reproduction and perception (colorblindness is common).  Symbolism works well for simple type relationships, but it’s difficult to represent taxonomy with nothing but icons.  Edge layout is the first and most expressive tool of block diagramming, but layout quickly runs into problems with scale.  Block diagrams are not the panacea of design modeling.

Large diagrams can become incomprehensible as they scale beyond a few 10′s of nodes. Most block-diagram notations allow an ad-hoc layout. Imposing rules upon the layout of the diagram can preserve comprehension and communicate additional information about structure. Resistance to orderly layout is itself useful information about structure.

There are some wonderful algorithmic graph layout tools that we can apply to help us make sense of things, but there are also a few simple manual layout tricks we can apply to finding latent structural patterns. It’s useful to know a few tricks for discovering structure when you are given a set of entities, but you don’t yet understand the relationships between them. It’s even more useful if these tricks can be applied at a whiteboard or in a spreadsheet without the need for expensive and/or complicated software tools.

Radial layouts equalize the significance of nodes and emphasize patterns between edges. They also scale up nicely.  These can be very useful for discovering relationship patterns in a system that is new to you.  You can make a pretty big circular diagram on a whiteboard with sticky notes for nodes and ink for edges.
Linear layouts are easy to draw.

They scale up decently, equalize nodes, and emphasize patterns between edges. They can optionally encode sequence along the node axis, but they don’t have to, and we’ll see why not encoding sequence is also useful.

Linear layouts are especially useful when we make a rule about the direction of the edges.

Any leftward edge that we can’t remove by reordering the nodes is a dependency cycle. Generally, you want to avoid such cycles in your design structure.  A useful consequence of such a linear layout is that it can easily be translated into a matrix of relationships between diagram nodes. The reason becomes more apparent when you orient the graph along a diagonal axis:

The graph can be represented as the matrix

Such an adjacency matrix can be referred to as a design structure matrix, or dependency structure matrix.  The tabular form of a design structure matrix makes it a useful tool for understanding the relationships of large interconnected systems.  A block diagram with 26 nodes may be simple, or it may be visually unwieldy. The equivalent DSM always has the same layout:


With our matrix form, we can apply simple row and column reordering to maximize the number of edges on one side of the diagonal.  The dependency matrix of a decoupled design can be made to have all of its edges under the diagonal.   Any edges above the diagonal that can’t be removed by row/col reordering are dependency cycles.

In a coming article, we will expand on this matrix technique to further understand and manage the structure of large systems. We may also discover something in the patterns of relationships that will help us to manage the work of building and maintaining such systems.