Five questions about the use of system modeling languages
The SysML modeling language, like any other, provides visual conventions meant to facilitate communication. However, this particular language might turn out to be the one too many, the one prone to impart the instability of a Tower of Babel to an organization. If implementation bypasses some crucial questions, the risk is high. In contrast, asking these questions may be an opportunity to enhance communication among teams.
| 1- What are the concepts? What are they based on? Are they structured?
These points aim at defining without ambiguity, and then structuring, the organization’s concepts regarding the system. They also aim at questioning relationships, synonymy, and homonymy. In other words, they aim at defining a system meta-model.
The meta-model reflects the culture and language of the organization even when, to ease external communication, turning to international standards is recommended. Norm ISO 15288 is the one to adopt for issues regarding systems engineering terminology.
Fluent communication originates in the common understanding of a shared semantic asset.
A meta-model relevant to the modeling objectives is true to the expectations in both scope and detail. For example, if the objectives are to implement a functional breakdown approach, the concept of function is probably sufficient. If the objectives also aim at considering parameter values in different simulation contexts, then the meta-model should be more complex.
Efficient communication only deals with the concepts it aims to share.
| 2- From natural language to modeling language: what is the methodology?
Next, the system meta-model needs to be translated into the modeling language. Appropriate translation rules must therefore be defined between the system meta-model and the meta-model of the language, and the resulting modeling rules must be defined as well.
In addition, model construction should be driven by a methodology structuring the textual documentation associated with the graphic modeling elements — the description fields of the elements—. Otherwise, the models might quickly turn into incomprehensible jumbles of boxes and arrows. This point is of the utmost importance, because the descriptions in the natural language capitalize the reasoning of the teams and the memory of the models.
Modeling does not preclude writing; it brings additional means of expression.
At the same time, a good methodology deals with relationships management. It optimizes delegation of relationship management to the tools to make it as transparent as possible for the users: It is easy to create links, but manually maintaining consistency between links throughout a project’s progress can prove to be very expensive.
It also deals with implementation on tools and addresses user friendliness by customizing model templates and user interfaces.
Modeling is a means to facilitate coherent thinking; it is not tool manipulation skill.
|3- What about spreading the methodology across teams?|
The production of modeling rules and methodology is the responsibility of experts who perfectly master the intricacy of meta-modeling. However, using the methodology in projects is the task of engineers whose expertise and project objectives are the building of robust system architectures. Besides, a good methodology is not enough. The teams must make it their own, and success calls for a communication based on practical examples taken from the organization’s field of activity.
Any means of communication may be considered: training (e-learning or conventional), handbooks, knowledge management systems…
Modeling calls for methodological learning and the provision of the means to learn.
| 4- By the way, what is a model? What is the connection with collective expertise?
A model is both an organized set of semantic units—the modeling elements—and the links between these units, the latter also conveying meaning. Although a model is much more than a collection of visual diagrams, the diagrams are parts the model. These specific modeling elements highlight the different subsets of links—and therefore intellectual connections—for different points of view.
In systems engineering, a collaborative discipline by definition, it is not possible to build a model behind closed doors even if the pen, or rather the mouse, is placed in the hands of a limited number of persons. A model records and expresses the results of interdisciplinary workshops. When a model is about to be finalized, complementarity among the diagrams can be checked. Beyond the diagrams, the consistency of the entire model testifies to the coherence of the collective thought.
A model is means to capitalize collective thinking and evaluate the maturity of projects.
| 5 – Is a model a deliverable? For whom? To what end?
A model capitalizes the results of many activities of system definition processes. The same model may become enriched from one evolution to the next throughout a project. Who says “activity result” says “deliverable”. Who says “deliverable” says “intended users”. Intended users are numerous in a system’s definition but few, most probably, will have a calling for learning a specialized modeling language. Models, though, allow for extraction of views in different formats, including the traditional formats of office automation. When model organization and customization are conceived to retrieve views specified in concert with the users, then the communication of knowledge can be adapted to their varied needs.
A model is a knowledge retrieval base of views adjusted for communication needs.
Françoise Caron, EIRIS Conseil.
This paper is the first of a series of three focusing on MBSE deployment. To be notified of the next publications, please consult EIRIS Conseil’s LinkedIn page.