On Systems Decomposition

March 24, 2021

*Dislaimer: here’s a brief link post on a topic that’s book chapter worthy.

Finally, your dream has come true. You’ll now get to build a project from the ground up. Finally, you can do everything right yourself instead of fighting legacy code written a hundred years ago by people you’ve never even seen.

How would you do that, though? How to build a system you won’t be cursed for by your successors?

I’ve already given half the answer—in some way—in my book. Basically, it’s all about the effects table (rus) and components (rus).

The effects table is a way to describe which effects get triggered by various operations (rus). Or, in other words, it’s a way to describe the program’s behavior—that is, its functional specification.

Components imply encapsulated state. The good old conceptual objects that comprise multiple objects of several levels in the runtime.

There’s just one catch. When you’re going from the functional spec to the components, that’s exactly what 'software design' per se is. And these days, people who can do quality software design are few and far between in our industry.

So the second part of the answer is an algorithm to take you from the effects table straight to components. The algorithm goes something like this:

  1. Make a graph based on the effects table. In that graph, the edges will contain the signals and the effects, but the vertices will contain the relation between them.
  2. Break the graph down into subgraphs. There should be high cohesion within subgraphs and low coupling among them.
  3. Voila, the components are ready. Each subgraph is a separate component that encapsulates the state changed by this subgraph’s effects as a result of processing the signals of the subgraph.

Surprisingly, this simple algorithm yields quite neat results.

Finally, here go the links that are the reason why I decided to write this blog post. I’ve recently come across two research articles written by a German-Israeli group that cover this very topic.

  1. Improving Design Decomposition.
  2. Functional Decomposition for Software Architecture Evolution;

Basically, they’re offering the same approach with just a few points to note:

  1. The best idea I’ll certainly use in my work is to split the reading/writing operations and assign different weights to them.
  2. They managed to come up with a plainer table structure. The rows contain operations, and the columns show all the different state variables.
  3. They came up with an idea to automate the process of breaking the graph down into subgraphs. Well, that’s scientists for you :) Or maybe they just kept ending up with graphs too large.

The effects table and the decomposition algorithm were the last—or so I thought—unique parts of the Ergonomic Approach. Well, in some way, it’s great the EA has no distinctive unique elements. It means that the EA is a mix of science- and industry-approved ideas, as opposed to a mix of some lone enthusiast’s idealistic delusions.