We talk a lot about “modeling language” in the world of systems engineering. That phrase gets used in a variety of ways with different meanings. It is the focus of discussions of standards. And yet, the variety of the usage of “modeling language” has some deleterious effects on the understanding of its implications for systems engineering and standards in particular. In this post we will discuss the term “modeling language,” its usage and role in the discussion of standards.
Often the context in which a discussion of modeling language arises is the consideration of standards. The underlying principle of standards as they relate to language is to “standardize” communication so that the dialogue using the language under consideration can be understood in the same way across an intended audience subscribing to those standards.
But, in the world of model-based systems engineering there are some subtleties regarding the term modeling language that are either not comprehended or are lost in the discussion. Most often, the discussion of modeling language turns on the symbology of the language—usually graphical—that is used to depict the model to the system stakeholders and other interested persons.
This is the language of symbols—boxes, lines, labels, shapes—that are combined to show the structure of the model. Whether the language used is that of business process modeling notation, structured analysis, unified modeling language, systems modeling language, mind mapping or any other system of graphical representation, it is a language used to describe the contents of a model.
This kind of language can be used to input information to the model. In tools robust enough to permit it, this kind of language can be used by the authors of the model to describe model aspects and characteristics which are recognized by the tool and made a part of the database model. This allows them to capture thoughts about the model design in a graphical way which can then be ingested by the tool and incorporated into the model, thereby adding new content or modifying the existing information. This is what we will refer to as using the language of graphical symbols in input mode.
The graphical language can also be used as an output vehicle. In fact, this is the use most familiar to systems engineers. The graphical notation is used to communicate information about the design to others—stakeholders, audiences, etc. In purely drawing tools, the graphical language depicts what the designer/draftsman has in her head as a “model” of the design. This “head-to-paper” workflow is surprisingly popular, utilizing tools like Visio or PowerPoint. In other tools, the data related to the visual depictions is saved, recovered, and revised in a rudimentary in and out usage of the tool. Instead of the “model resides in the head” approach, advocates of this tool encourage the belief that the “model” resides in the accumulated visualizations. The problem with both of these approaches is that it is extremely difficult to maintain consistency and completeness. In both approaches, the visualizations have an “information out” function communicating the design to others.
In more robust, sophisticated system modeling tools like Vitech’s GENESYS™, the same input/output functions for graphical notations hold true, except that they actually send data to and from a database model. But beyond simply acting as a repository of that information, the database is structured by a semantically rich schema with defined concepts and interrelationships grounded in the practice of systems engineering.
NOTE: At this point, we need be clear about what me mean by two often used and misused terms, “schema” and “metamodel.” For purposes of this discussion we will use “metamodel” (or, more accurately, “systems metamodel”) to mean the abstract model in which our real-world design models are conceived, while we will use “schema” to mean the data structure that is instantiated in a database to provide a framework on which to create the digital model of our design. So, the schema is the metamodel realized in a database.
This gives rise to the necessity for a language apart from the graphical notation of the input/output language. In the Vitech tools, this is founded on the language of entities, relationships, and attributes. Entities are the building blocks of the system (e.g., requirements, functions, components, items). Relationships connect the entities in prescribed ways, while attributes describe the entities and relationships. Information captured from the inputs of the systems designers is captured in the database as provided in the schema and according to its rules. For example, entities may be connected to others by the relationships allowed between them by the schema.
This language of the metamodel/schema can be understood in terms of human language constructs. The entities are nouns, the relationships verbs and the attributes adjectives (describing nouns/entities) or adverbs (describing verbs/relationships). In a simple example, the relationship of requirements to functions can be “read” as requirements (noun/entity) are the basis of (verb/relationship) functions (noun/entity). Extended to a useful level of detail, this schema becomes very powerful in the hands of designers. The tool can use the schema to suggest possible relationships/attributes, warn of mistakes and check for completeness and consistency. This powerful language for model construction is the true modeling language—the language of the metamodel. This powerful language is also a language of reasoning—reasoning about the system architecture and its sufficiency well beyond a library of notation and visualization.
Because the other language—the graphical notation of input and output—is more visible, it creates the misimpression that it is the “modeling language.” This tempts the advocates of standards to standardize the way model aspects are represented rather than standardize the way models are constructed. But representation is in many ways domain specific. Different representations speak to different audiences. What resonates with software engineers may be confusing and meaningless to business process owners. By insisting that the consumer of the representation learn the language of the system designer, the power of systems engineering is denied to anyone outside of the sphere of that language.
Standardizing on a specialized representational notation limits the audience. The representational language should be as broad as the desired audience. The broader the menu of representations, the more powerful the tool because its ability to speak is expanded. Limiting the menu in the name of “standards” is a path to limiting the power and scope of systems engineering.
It is actually the language of the metamodel/schema that is important to us. This is the language that matters and the language which could benefit from standards. Of course, before a tool can benefit from a metamodel/schema, be it standard or not, it must actually have one. Tools that operate from data that resides in a document—or even in a pile of documents—cannot benefit from a common metamodel or an agreed standard.
Until the standards discussion centers on the language of the metamodel, it is not focused on the real modeling language. True standardization and alignment must occur at the conceptual level. We must simply stop attempts to limit the language of the communication of the model and engage with the language of model construction. So the next time someone tells you that there should be only nine diagrams and a standard to make that so, understand that they have not comprehended the real meaning of “modeling language.” Resist that argument and instead spend your time with the systems metamodel.
