By Dean ~ November 12th, 2008. Filed under: Industry, Observations, Systems Engr..
As we exchange ideas about system design, several questions keep coming up, often under the guise of disagreements. For example: What is a model / modeling language? What is an execution language? Do you separate implementation / execution from analysis? Should you? We’ve been kicking these issues around for some time. It’s unfortunate that so many of us have continued operating with different implicit understandings. It seems as though it’s time to start thinking about normalizing our terminology. Let me explain why I’m on this track:
We recently completed an evaluation with an ASIC designer who concluded that he didn’t really need a different modeling environment because Verilog was both his modeling language (fully documented his intent, easily understandable by his constituents, independent of modeling tools vendors and – big bonus – fully executable) and his implementation language. Then, I saw this multi-blog discussion thread on Business Process Modeling Notation (BPMN) versus Business Process Execution Language (BPEL). Again, the issue seems to be coming to an agreement on the definitions of the terms modeling, simulation / analysis and execution. I even thought back to the very first time we tried to write a real program using C++. This was before a language compiler was available, so you ran a pre-processor which generated marginal C code that sometimes compiled and was impossible to debug. One could argue that, back then, C++ was a modeling language, but some of us wondered whether it was really an implementation / execution language. Probably at the unfortunate expense of our development productivity, we have spent a fair bit of time debating the implications of this lack of shared understanding around the terminology in our space.
For me, at least, this situation brings to mind the parable of the elephant and the blind men. Each engineer understands the characteristics of models / modeling as they apply to his problem space. He is also completely comfortable with the concepts of simulation, analysis, execution and implementation as they apply to the system as he defines it. The difficulty comes about when we try to develop canonical definitions for the terms and apply them uniformly across systems ranging from Deep Space Mission platforms to digital wristwatches. Any definitions general enough to cover all cases are essentially worthless and any useful definitions are, at least somewhat, context dependent.
Since we can’t seem to address this issue with finality, we’ve decided to try our best on this blog to always explain our perspective and to stipulate the definitions we’re using. If we drop the ball on this, please call us out. If you think we’re heading down a rat hole with something, please let us know. We welcome all opinions and points of view.