People use the word model in many different ways. They might mean a fashion model or a model plane or a financial model. The kinds of models we focus on are those that “represent” some aspects of a physical reality. It might be the images that make up a model of the human body, or a plastic figure that contains representations of the major systems. It might be a scaled rendition of a plane or a ship or even a set of plans for a landscape design.
One way to describe the concept of model would be to see the model as a “hypothetical description of a complex entity or process.” The plastic plane is a tangible description of the real thing. Models can be “literal” like a toy car that mimics the “real” automobile or they can lie anywhere along a spectrum from the literal representation to models that exist as a set of equations or simulations like a complex financial model.
For the purposes of systems engineering the system models that we consider lie at the symbolic end of the spectrum. In this sense we mean specifically models of systems or “systematic representations of systems.” From an engineering perspective the model must span at least four domains (requirements, behavior, physical architecture, and verification & validation). It must also consider and describe the entire lifespan of the system from problem identification to the initial concept to retirement.
It is important to note that graphical representations standing alone are NOT the complete model. They express aspects of the model but, in our context they are not complete enough to be seen as models themselves. They are representations that derive from the model. Taken together they can give us a detailed picture of the model but they are not the model itself.
One of the critical aspects of a systems engineering model is that of relationships. In a global sense the system relates to the external world in a variety of ways that must be captured in the model. Internally the system components relate to each other. This is very similar to the global relationships of the model to the world around it. This becomes apparent when we think of a component as a “system” and the other components as “externals.”
This is why the graphical representations are not sufficient to depict the system but must be webbed together with a “language” that expresses these concepts. The language sets up relationships between the system and its externals and between the internal system components. This makes the model robust and ultimately, executable. Without the relationships the most we can have are symbolic representations of the model.