Before addressing “language” and its usage in model-based systems engineering, we need to briefly examine the term “model” as well. The term model is primarily a thought construct to determine what is necessary and sufficient to describe and specify a system, although not limited to system description and system specifications. The “model” ought to encompass the system’s life cycle too. The “model” is the means we use to “think” about the problem at hand. Model, in this sense, is much broader than the more conventional usage. Conventional usage nearly always sees a model as a graphical view or possibly many graphics, all related, or some scaled down physical representation of the system. These graphical representations or scaled representations comprise part of the model in model-based systems engineering, but the representations alone are insufficient to serve as a system model.
If a model then, encourages and facilitates us to think, then what do we think about? How do we think about the system? When should we think about certain questions? How do we gain insight so that we can develop successful systems? Is knowledge of a system’s parts sufficient to design a system? All of these questions are expressed using language concepts.
Russell Ackoff’s examination of the difficulties encountered in developing systems and managing system development is laid at faulty thinking and proposes what he calls “synthetic” thinking. Ackoff states that “[s]ynthetic thinking is a way of thinking about and designing a system that derives the properties and behavior of its parts from the functions required of the whole. The whole has properties that none of its parts have. Analysis of a system reveals how it works but synthetic thinking is required to explain why it works the way it does. Systems thinking integrates the two.”[1] The difficulty with analysis alone is that it breaks down a system into leaf-level components. Each component expresses a behavior and the analysis seeks to explain the behavior. Once the leaf-level component behaviors are explained the attempt is made to explain the behavior of the whole from the leaf-level components. Russell Ackoff notes that this approach by itself cannot succeed because a system broken apart loses all its essential characteristics; similarly for the parts. Leaving those using analysis only as knowing how a system works but never why it works the way it does. This distinction between how a system works and why it works is important and effects how one performs systems engineering. This is the heart of model-based systems engineering as advocated by Vitech Corporation and its Chief Methodologist, Jim Long.
Our manner of thinking then affects our success or failure at understanding and building systems. This leads into understanding how the mind comprehends objects and the importance of language.
—
[1] Russell Ackoff Interview, Strategy & Leadership, Vol. 31, No. 3, 2003, p 21
This reminds me of the "model" done for the IBM S/360 computers. The word descriptions ran to several volumes, plus a big book of "exceptions" requested by hardware implementors for each specific machine model within the 360 architecture due to different interpretations of the word based model.
The baseline S/360 architecture was 100% completely and 100% accurately described in a small booklet by using APL.
[APL = "a programming language" invented by Iverson at Harvard, and then implemented at IBM. see:
http://en.wikipedia.org/wiki/APL_(programming_language) ]
The big advantage of APL was that it was concise and precise while being 100% accurate. For describing the S/360 architecture it was perfect.
Systems Architecture and Systems Engineering needs a better way to model than things like SysML et al which do not fully address our modelling needs. APL is not able to address these problems, but could serve as inspiration for a method and language that does.