Model-based architecture (MDA) or model-based development is an idea that to me comes from the automotive field. To, it means that you use some tool that is capable of modeling both a computer controller system and the environment being controlled to create a simulation world where computer control and environment meet and the characteristics of the controller can be ascertained quickly. The key is to not have to convert controller algorithms to concrete code, and not have to run concrete code on concrete hardware against physical prototypes to test the controllers. Today, this seems to be applied to many fields where you are creating control systems (automotive, aviation, robotics). The tools are math-based like MatLab and LabView, along with special programming environments based on UML and StateCharts.
What is interesting is that most of these tools are graphical in nature. And they do seem to work quite well, which is quite surprising given the otherwise poor record of graphical programming as opposed to text-based programming. There were a pile of graphical programming environments in the 1980’s, none of which amounted to much. What survived and prospered were the good old text-based languages like C, C++, Java, VisualBasic, etc. In practice, it seems like it is very hard to beat sequential text when it is time to actual get code working. More efficient programming seems to boil down to having to write less text and having text which is easier to write (for example, dynamic typing, rich libraries, garbage collection, and other modern language features that remove intellectual burdens from the programmer).
But graphics do seem to work for domain-specific cases (like control engineering or signal processing), especially for data-flow-style problems. And for abstract architecture work. So there has to be something to it… but what?
Now I read a blog post by Frank Schirrmeister at Synopsys who points out something quite interesting that I had not quite thought about before:
So my conclusion for now is that in refinement from one abstraction level to the next more detailed one, graphical refinement will work fine. However, when being at a specific abstraction level, textual entry using an expressive language is more elegant than graphical design entry.
Does this make sense? I am looking forward to your thoughts and comments!
That actually would seem to agree with my observations over the years. I think I would also add the note that graphics do not work well in being as general as text-based languages. For example, doing counted loops in graphical notations, it usually ends up being plain contorted. Maybe because the actual act of looping back in a sequential flow is really not particularly graphical in practice. Another example is fan-out. One of the best examples I have seen of this problem is actually owned by Synopsys nowadays… I have seen some examples of the old Virtio “MagicC” language where you have a decision box and then tens of arrows to different function boxes based on the address entered… just painful. For something like that, a plain list of text is so much more powerful. Once you have thousands of different addresses to decode, graphics only hide the essentials.
But Frank’s observation really is telling here: it would seem that once you are at a particular level of detail and really have to sit down and get code to work, text works the best. However, we must recognize that in much design practice, we do have a long exploration and design phase first where graphics definitely help and code will just lock you down unnecessarily.
So there is a place for both, I guess.
Great, we actually agree!
One clarification on MagicC though. It is really a combination of plain C with 12 graphical constructs from SDL defining “what if” decisions etc. The case you describe *should* be done in text, not as a decision graph. MagicC users really like it for entering peripherals easily using larger chunks of code (like the example you suggest). Between the blocks they can maintain graphical “what-if” trees, which allows them to easily grasp the basic control structure of what is going on.
Overall this fully supports Mike Keating’s notion of entering data using one-dimensional textual language and reasoning about it using two-dimensional diagrams.
Thanks for the clarification, always appreciate that! It was expecting that MagicC did something along those lines, since it had provably been used to successfully model non-trivial hardware. And the pain of doing that using just graphical diagram is the kind of thing that I would expect an engineering department to quit over 🙂
I more and more agree with the reasoning with graphics, entering information with text argument.