“Model” and “view” are terms that are used somewhat loosely in the world of systems engineering. Often they are used interchangeably. Frequently, the imprecision of their usage causes confusion.
Careful consideration of these terms can offer some help in clearing away the confusion. Many model definitions feed this imprecision. Consider, for example, “A model is an approximation, representation, or idealization of selected aspects of the structure, behavior, operation, or other characteristics of a real-world process, concept, or system.” (IEEE 610.12-1990) This definition is fairly typical, embodying the usual characteristics of being a representation or abstraction of some subset of the aspects of a particular reality.
While it is perfectly fine in its context, the definition creates a problem in distinguishing between models and views. Views, which might be pictures, diagrams, or textual descriptions of various aspects of the reality, can easily be considered models under this and similar definitions. But doing so can lead to a loss of some of the power available in a system where models and views are understood differently.
There is a strong value-add to be had from understanding documents and views in relation to models rather than seeing them as interchangeable concepts. In the document/view centric world, each document/view stands alone as a “model.” The idea is that these models add up to a system description in the aggregate. But there are several traps embedded in this approach.
Such an approach guarantees that any change in this system design/description has to be propagated across all the documents. This means that advancing the design is slowed by the need for manual consistency work with every change followed by a ripple of checking and modifying the documents. That adds time and drags down responsiveness.
In addition, there is nowhere for the relationships to reside from representation to representation. Without a larger model to contain the documents/views their relationships are weakened. Without those relationships the overall model is dismembered or, arguably, does not exist at all in any tangible way.
A better approach involves a model that offers different views in order to serve different purposes. Here, a view is a representation of a system from the perspective of related concerns or issues. (IEEE 1471-2000) The value-add in this approach comes from the integration of the views into a single model. This is the most powerful manifestation of the model-based systems engineering (MBSE) model.
With the MBSE model all the elements of the system are held in relationship to each other. The documents/views flow from the model as structured answers to particular queries of the model. When changes are made to the model they are then reflected into these answers (documents) and can be seen in “real time.” The change is reflected across the model and into the documents and the engineers can move on to the next change. All the documents stay up to date all the time.
The value of this ability to skip the checking and updating of every single change is easily understood by any organization because it represents a real savings in effort and an increase in quality. In addition, with the right tool, changes can be made through the documents/views into the model. This means that altering something in a behavior diagram actually changes the underlying model relationships accordingly. Querying the model for a new document will result in an answer that already reflects the change. The tool provides an underlying database model that does not require direct work by a database manager but can be updated through the documents or views. That means engineers can be freed from database management chores and returned to function as engineers.
These two value propositions are powerful levers in helping project and program managers to understand the value of MBSE, especially MBSE in the context of a powerful tool. No more reworking the documentation and worrying about consistency. With MBSE the model takes care of those concerns and produces current documentation in real-time response to point-in-time queries.
The foundation of this power is the understanding of document/views as answers to queries of the larger model where the query defines the set of information to be conveyed in the view produced in response to the query. This allows the model to function more powerfully as more than a view or even a set of views.
