Software Architecture Today
The current structure of software architecture is dominated by the if-then-else (ITE) structure even in the object-oriented world. Decisions are made in every domain of software. Applying “If<state> then <data manipulation> else <data manipulation>” software experience to a couple of everyday experiences will make this a little clearer.
Imagine that a book has the table of contents, footnotes, other references, and the index embedded in the text. Literally every sentence and paragraph would have some information indicated or referenced by the contents of the sentence and paragraph. This insertion would make the reading experience almost impossible.
Imagine a movie where that long running list of people at the end of a movie is embedded throughout the movie. Every scene would provide the actors name as they appear, would list the legal team whenever a legal issue was discussed, the catering people when they fed the actors and staff, the location information would appear when the location changed. The list of references would appear when the gaffers or best boys created part of the scene structure. Now you’re watching an exciting stunt scene and the stunt double comes in and the screen annotates the stunt double, the makeup artist, and the editing team to make the scene seamless. All of the injections would be so distracting as to make the movie experience unpalatable.
Software does exactly what I’m describing. The decision-making aspect of software is embedded with data manipulation. If<state> then <data manipulation> else <data manipulation> “where am I” repeat as needed. This is what has been called spaghetti code (yes the picture is calamari but you get the idea) for decades because the “where am I” aspect needs a “go to”, “come from”, or other sort of direction for where execution should be. The existing software structure of if-then-else (ITE) mixes process-flow and data-flow. The “go to” aspect of object-oriented software still exists. There is no explicit temporal control, all temporal control is by the <state> as in “should I execute here?”.
Books and movies are orthogonal, they separate the references from the content. In 2002 my patent issued on the orthogonal software architecture: COSA. The patent is “Free” of any license. I have published a number of papers, presentations, been a speaker at conferences, and wrote a book published in 2009 all about COSA. In 2005 CMU-SEI published a presentation “Personal Software Process for Engineers: Part II. Designing and Verifying State Machines”. Search for “L7 State Machines.ppt”. On slide 49 a matrix is displayed to show how to decompose a problem. The beauty of this matrix is that the columns are orthogonal. Unfortunately, they don’t carry the matrix into the solution, their work results in ITE.
COSA eliminates spaghetti code and the free COSA approach has several additional benefits they are: temporal, preemption control, dial-in inherent trace, DSPL, orthogonal, and modularity. COSA lends its structure to code generation, something that is nearly impossible with ITE. Costly updates can be eliminated with DSPL, and documentation can be automated because the process-flow and data-flow structures lend to that kind of automated analysis.