Select and deploy a conceptual modelling language. Some Keys.

[This post is also available in French]

Choosing one or more conceptual modelling languages as part of a Model Based System Engineering (MBSE) approach necessarily involves “professional introspection” in order to clearly define the motivations (modelling intentions) to be supported. No matter which choices are made, they are less important than the justifications that lead you to make them, and the know-hows that they are used to magnify. Communications, which are fundamental to the success of an MBSE deployment project, must be based on these know-hows. Finally, the deployment of MBSE is a long-term, incremental process that takes place at differing paces within an organisation. The command of the coherency of the models and the corresponding intentions must be considered as a major issue.


Model-Based System Engineering[1] (MBSE) is clearly very topical (46.4 x106 hits on Google, compared with 20.4×106 hits for “Computer-Aided Design”), which is quite pleasing, because we firmly believe that MBSE[2] is a basic technique that will allow us to better address the complexity of the systems to be built and to reduce their costs and the time its takes to bring them to market. While the choice of a modelling technique is not exactly a Cornelian dilemma for certain types of models (Matlab, MGS[3], etc.), this is not always the case for others, and for conceptual models in particular.

This article is not intended to be dogmatic and tries to rise above the clan warfare that unfortunately rages in the world of conceptual modelling. It attempts to give the readers the keys they will need to form an opinion on the approach to the deployment of MBSE that is best suited to their organisation. After briefly looking at the fundamentals of conceptual modelling, we present a classification of some of these conceptual modelling languages and some of their characteristics that can be used to make choices. We then address the main problems encountered when deploying MBSE, irrespective of the languages that are chosen. 


Before continuing with the article and presenting the keys that the readers are expecting, we think that it is important to briefly place conceptual modelling in its historical and teleological (the study of purposes) context. Conceptual modelling can be considered as a technical and pragmatic branch of semiotics (the study of signs and their meaning), which is rooted in John Locke’s 17th-century epistemological (a field of scientific study) work, “An Essay Concerning Human Understanding”[4]. By accepting this assertion, we emphasise the importance of critically studying the method, the logical forms and the modes of inference that are used in the field of activity targeted by the conceptual modelling, when adopting a conceptual modelling approach. Adopting a conceptual modelling approach amounts to attempting to command the famous semiotic triangle – Reality, Concept, Sign – in a given context[5]. 

We can put an end to the theoretical discourse and become more prosaic by shifting to the context of system engineering, where conceptual modelling serves a number of purposes[6], such as for example:

  • the elicitation of the needs
  • the functional specification
  • the behavioural specification
  • the optimisation of the interfaces and the quest for the optimal architecture
  • the automatic generation of the code

Conceptual modelling can achieve this by simplifying a reality as concepts that take implicit know-how onboard, and representing them as signs that are easier to manipulate, analyse and communicate.


Figure 1: two examples of notations for the modelling of systems

Conceptual modelling was developed in the field of software engineering in the 1970s, but only became truly popular in the 1990s. This period coincided with a change and a crisis in the software industry, concomitant with the explosion of the internet bubble, which had a number of consequences on conceptual modelling:

  • an over-emphasis on conceptual modelling tools, and therefore languages (Booch, OMT, UML, etc.), to the detriment of methods,
  • and even worse, the inversion of the causal link between the intention/purpose and the act of conceptual modelling itself: “Conceptual modelling is practised by computer engineers who are seeking to automate the production of code. Therefore, it is not adapted to anyone who is not a computer engineer…”.

 However, it would appear that a certain degree of maturity in conceptual modelling tools has been reached in recent years, and that the modelling intention has been restored to its rightful place. This also explains the growing popularity of Domain-Specific Modelling Languages (DSML). 

Whether a DSML or a so-called “standard” language is chosen, navigation must be guided by the intention/purpose of the modelling. We will look at this point in more detail later on in this article. 


Several different modelling languages have already existed for some time. It can be hard to find one’s way between the *MLs derived from UML[7] (SysML, SOAML, WebML, etc.) and the other languages, such as AADL[8], SDL, Modelica[9], etc.

3.1. A classification of existing languages

We will now try to draw up a multi-dimensional classification of these languages. 

  • The scope of purpose: what is the objective of each language? Is the language very general? Does it cover a broad range of different problems, from the initial analysis to the detailed design? Or does it aim to solve a specific problem in a particular domain? The complexity of the language may well be proportional to its scope of purpose. UML 2 is one example that aims to be universal, with its 14 different types of diagrams. SADT[10], on the other hand, attempts to remain independent of the domain, with its two types of diagrams, but clearly focuses on the analysis, rather than the design, of systems.
  • The level of semantic formalisation: the distinction is often made between formal languages, for which a mathematical representation is possible, meaning that the properties of the model can be proven mathematically, and semi-formal languages, such as UML, in which a certain degree of formalisation is proposed, but in which ambiguities, or “points of semantic variation” remain, which prevent any formal proof. For example, if we consider several UML modellers that propose simulation capacities, it has been demonstrated that the same conceptual model (e.g., based on state diagrams) can produce different, or even contradictory, simulation results, depending on the tools. 

The following can also be added to these first two dimensions:

  • The level of distribution: there is a huge difference between the worldwide and transverse distribution of UML in all technical fields and the limited penetration of SDL outside the field of telecommunications. Similarly, formalisms like Grafcet[11] are not widely used outside France.
  • Standard, as opposed to proprietary: here again, advantage goes to the colossal works published by the OMG[12]! The specifications of UML and SysML are public. Consequently, there are countless commercial tools in competition for the potential users. Certain interesting formalisms, including those of the MATLAB/Simulink tools, have the serious shortcoming of being proprietary, which means that any users who adopt them are inextricably bound to the sole publisher of the support tools and incur all the known corresponding risks (non-competition, upgradeability, long-term durability, etc.).
  • The existence of an ecosystem: this criterion is often linked to the preceding one, because standard languages stand a better chance of proposing a diverse and varied offer. Nevertheless, a few proprietary languages have a rich ecosystem, thanks to their pre-eminence on niche markets, while some standard languages are not widely used and, therefore, have a relatively poor ecosystem.
  • Adaptation to the users’ culture: the more a language is general, the higher the risk that it will be far removed from its users’ culture. Moreover, since languages like SysML, used in system engineering, are derived from UML, used mainly by computer engineers, they barely conceal the “object-oriented” concepts, and run a high risk of missing their target, or at least of leaving the uninitiated on the wayside.

3.2. The advantages of UML / SysML

UML has now existed for more than 15 years and has become a de facto international standard ( It is the result of years of work by internationally renowned experts[13], who have given the language great powers of expression (the number of concepts and diagrams) and excellent coverage of common modelling needs. Using UML is a good choice for anyone who wants to analyse and design their architectures without having to define a new language (which requires particular know-how), while benefiting from the confidence that can be placed in a standard notation. UML is well suited to describing high-level concepts and to defining a general glossary that is used to describe the project’s concepts, thereby facilitating broader communications.

The ecosystem around UML ( is very rich, in terms of the number of modelling intentions based on UML (known as profiles, such as UPDM, MARTE, TelcoML, BioML, etc.) and of the multitude of modelling tools ( that can be used to implement them. Not only are these tools used to create UML/SysML models, but they can also automatically produce documentation, establish links with textual requirements, generate code, etc.

Numerous professionals are trained in UML/SysML in engineering schools and universities, or even earlier in France, where SysML was recently introduced into scientific secondary school curricula.

3.3. The disadvantages of UML / SysML

However, the advantages that we have just mentioned are offset by real disadvantages that must not be underestimated. 

First, the apparent complexity of UML, due to the high number of available concepts and diagrams (14 different types of diagrams since UML 2.3), cannot be denied. Unfortunately, this complexity is poorly masked by the existing tools, which remain difficult to command, unless a significantly reduced number of diagrams is used. The tools are also difficult to personalise, in particular in order to restrict the diagrams and the command palettes in each diagram, which would precisely be a means of combating this apparent complexity. 

Consequently, it is absolutely necessary to define a detailed modelling approach (intention) very early in the project in order to choose the necessary and sufficient subassembly of UML to be used and to avoid becoming lost in the meanders of the language. The order in which the selected diagrams are to be used must also be defined sufficiently early, ideally resulting in a model template, produced with the selected tool. These methodological efforts demand the help of experienced mentors, who are not always available in the company. 

In the special case of SysML, the object-oriented origins of UML, from which it is derived, are only partly masked (the notions of operation, generalisation / specialisation and even of object flows and object nodes in the activity diagram). These object-oriented origins are clearly an obstacle to adoption by system engineers who are not familiar with the world of software development.

3.4. The advantages of specialised languages (DSML)

Specialised languages target a particular domain or a particular modelling intention. This means that they can capture information with a higher degree of precision, leaving less room for interpretation. Due to their reduced coverage, most specialised languages are semantically richer and more formal and are often capable of more advanced verification and generation. Therefore, DSMLs attempt to strike a balance between the scope of purpose (narrower than that of a universal language) and semantic formalisation (which is richer). 

Specialised languages should also be more meaningful to experts, because they use the specialised vocabulary and concepts of the domain, rather than more general concepts that are further removed from the user’s culture. Similarly, the number of diagram concepts is much more limited, making the language easier to learn. Their implementation is also facilitated by dedicated tools, which can be very compact and efficient.

3.5. The disadvantages of specialised languages (DSML)

The major pitfall of reinventing the wheel must be avoided. If the DSML ends up by resembling UML too closely, then it is preferable to directly use UML, or a subassembly of UML. Even if UML has its shortcomings, they are known, and some of them can be overcome. Creating an unnecessary DSML could result in repeating a number of errors that have already been resolved by UML. Finally, the creation of a metamodel and of a tool to use it demands a particular know-how that often is not available in an organisation. 

3.6. Towards a hybrid approach?

It is not compulsory to choose between a “pure” DSML and xML. While DSMLs can be created from scratch, they can also be created in the form of UML profiles. In this latter case, the person who defines the language and its environment of tools will be able to benefit from all the conceptual foundations of UML and its ecosystem. On the other hand, expertise in the UML metamodel is necessary, a fact that may constitute a major obstacle. 

A “pure” DSML does not demand any knowledge of UML. But in this case, we have to develop the entire infrastructure supporting the language ourselves. A recent attempt in the realm of system engineering is illustrated by the open source Capella tool (, based on a formalism initially defined by Thales to meet its own needs. The company’s system engineers could not find their preferred functional approach in standard languages, such as UML and SysML. So they decided to create a DSML that is better adapted to the culture of their users and is inserted in a modelling method called ARCADIA ( The recently launched Clarity project ( aims to create an ecosystem around Capella. 


As we stated earlier, conceptual modelling simplifies a reality as concepts (see Chapter 2).

The nature of these concepts and the manner in which this reality is conceptualised depend closely on the know-how and the experience of the modeller. It is important that this know-how is described in one way or another that:

  • facilitates the action and the teaching of modelling,
  • acts as the basic documentation for the definition of the modelling environment.

Moreover, the description of this know-how avoids the “blank page” syndrome amongst less experienced modellers. The work done to describe the know-how is more or less formal and is done differently, depending on whether we choose to support the conceptual modelling process with a standard language (UML, SysML, AADL, etc.) or with a dedicated language (DSML).

4.1. Magnifying know-how

When using a standard language, the know-how should preferably be documented in the form of operational guides that pragmatically present the modelling process.

This work demands at least two skill sets:

  • thorough knowledge of the language’s metamodel,
  • thorough knowledge of the specific modelling domain and the corresponding practices.

In the specific cases of UML and SysML, these guides are simplified by setting up adapted profiles.

When using (or when intending to use) a dedicated DSML, a totally different and much more conceptual approach must be adopted. Even if, ultimately, writing operational modelling guides may be useful, in this case, it is important to consider this know-how as the requirements that the DSML must meet. To do this, we must produce:

  • conception scenarios expressed in the language of the domain (i.e., without any reference to modelling artefacts),
  • coherency rules applying to the data of the domain.

These factors form the requirements for the development of a metamodel that structures the dedicated DSML.

 In terms of change management and communications, the promotion of this know-how helps the adoption of conceptual modelling techniques to be accepted as a simple tool, rather than a cultural revolution.

4.2. Developing, rather than revolutionising, know-how

The implementation of conceptual modelling techniques is clearly an opportunity to improve engineering practices. But, to stand a better chance of being accepted, these techniques must not call existing know-how into question excessively, or, even worse, lead to it being forgotten. Once the new practices have been established, their gradual improvement will also provide an opportunity to improve engineering know-how (or to benefit from its improvement). 

Here again, the choice between a standard and a dedicated language will have a particular impact.

If a dedicated language (DSML) is used, changes in the know-how will result in changes in the metamodel that fundamentally structures the language, thereby incurring a technical risk.

If a standard language is used, changes in the know-how will only bring about changes in the guides and/or the modelling profiles (in the case of UML or SysML) and will incur few or no technical risks on the language. But for languages that can be profiled (UML, SysML), the technical risk of the language depends on the complexity of the modelling technique, because it is a function of the combination of the complexity of the metamodel of the language and of the implemented profile.

In conclusion:

  • even if conceptual modelling is a particular activity, it must allow for business practices, and not the opposite, or it could be rejected by the team and become ineffective,
  • depending on the maturity of your engineering know-how, its complexity and the level of support of these know-hows by your modelling environment, the use of a standard or a dedicated language will be more or less in your technical comfort zone.


5.1. Preamble

We believe that it is important to keep a “configuration management” vision in mind when deploying an MBSE approach, in order to be ready, when the maturity of the initiative and/or the number of models demand it.

In conceptual modelling, it is important to remain humble about the choices you make. Choosing a modelling technique at a point in time t, may no longer be justified at t + Δt, or this technique may not be sufficiently adapted to a different technical and/or organisational context. Consequently, when we deploy a model-based engineering initiative, we may handle a series of models based on different modelling techniques (use of standard and/or dedicated languages).

The usage modalities[14] of modelling techniques based on standard languages may differ according to the context, while modelling techniques based on dedicated languages obviously call on different metamodels, depending on the target domain. Adopting a model-based approach obviously implies that “correspondences” and “traceability” exist between the artefacts of these models.


Figure 2: an example of the possible relations between models and modelling intentions


If the dimension of “time” is now added, these models, and the modelling techniques (intentions) both evolve.

Figure 3: which versions of the models and modelling intentions are compatible with which versions of other models and modelling intentions?

It appears to be necessary to coherently manage the relations that exist between the models and the intentions. Examples:

  • each version of the “Orbit Segment” architecture model is only compatible with a certain number of the versions of the “marketing needs” (it meets these needs).
  • each version of the “Orbit Segment” architecture model was produced according to a particular version of the “Command the technical and functional interfaces” modelling intention, but it still remains “compatible” with all the versions of this modelling intention.
  • For more effective cost control, we are going to change the cost allocation method, thereby creating a new version of the modelling intentions “Commanding the technical and functional interfaces”.

This situation is clearly delicate, and some might say that it can be resolved by using a single model.

If we decide that the paradigm of the single model (or even of the single “usage modality” / “modelling intention”) cannot be envisaged, then we have to accept this and deploy the means of controlling these coherences. Managing the coherencies amounts to deploying the configuration management techniques (baselines) of these models:

  • management of the versions of the modalities/intentions,
  • management of the model versions,
  • management of the compatibility/applicability of the models.

5.2. Modality version management

A usage modality must be represented by a document that explains/substantiates the manner in which the language is used.

As a general rule, standard modelling languages have a set of adaptations of the supporting tool and, in the case of UML/SysML, a particular profile.

Dedicated modelling languages must have a set of creations[15]/adaptations of the supporting tool, based on a metamodel.

Therefore, modalities version management consists of managing the configuration of the following elements:

  • the document explaining the modality. This document must refer to other applicable documents that must also form part of the configuration:
  • technical process documents,
  • business process documents,
  • methodological documents.
  • metamodel / profile,
  • tool adaptations.

5.3. Model version management

Models must be produced according to a particular modality.

Therefore, model version management consists of managing the configuration of the following elements:

  • the modality,
  • the model (and the “included” models[16]).


5.4. Management of the compatibility/applicability of the models

As we stated earlier, a model is never unique and may be related to other models:

  • that it includes (e.g., the “Engine ” model includes the “Brakes” model),
  • from which it is derived (e.g., a model intended to automatically generate real-time synchronous code may be derived from a preliminary design model that does not demand any particular skills in synchronous real-time systems),
  • with which it has correspondences (e.g., the “Engine” model has correspondences with the artefacts in the vehicle’s mechatronics model.

If the configuration management of this network of models is to be properly controlled, it must rely on a methodological framework based on compatibility rules.


  • a model can only include models based on the same modality/intention,
  • a model can only be derived from another model if it shares the same “technical process” type[17] applicable documents with the latter, or at least applicable documents that are considered to be “compatible”,
  • a model can only have correspondences with another model if it shares the same[18] applicable documents with the latter, or at least applicable documents that are considered to be “compatible”.

 It is important not to be afraid of this complexity, which is the “right” price to be paid in order to benefit from the significant gains made by deploying a model-based engineering process.


Deploying an MBSE approach is never a trivial matter. It is necessary to be pragmatic, without being naive. We can forget the dream of simplicity that is promoted by the publishers of modelling tools. Simply buying a modelling environment with its tools is not enough to be in a position to deploy model-based system engineering.

First, it is necessary to implement a conceptual modelling approach and, therefore, to precisely define the intention(s)/objective(s) of the modelling process. Then, we can choose the modelling language: either one of the variants of UML, or a DSML that we build ourselves. It is important to note that we cannot make an absolute value judgement of the different languages in this classification, due to the importance of the modelling context.


  • if you plan to make a move towards conceptual modelling, but you are not sure how to go about it and you run into difficulty determining the modelling intentions, then you should not even consider a DSML, because the risk of failing to provide the right modelling solution on time is too high,
  • if many newcomers are involved in your modelling initiative, then the use of a so-called standard language may give rise to too many different interpretations and, ultimately, will fail to convince the users.

Clan warfare aside, simply consider the languages at your disposal as a set of tool kits. And if you cannot find what you need amongst these existing languages, then consider creating your own DSML, especially since high-performance meta-tools now exist to help you to build your own modelling environment. One example is the open source Sirius tool from Thales and Obeo (, or its commercial equivalent Obeo Designer ( By way of example, Thales used the technology implemented in Sirius to develop a system modelling tool for its ARCADIA modelling initiative (Capella).

You should start from the principle that it is highly likely that you will quickly have to manipulate a set of models based on different modelling intentions/objectives and that you will have to manage them coherently (configurations) if you want to avoid being overwhelmed by the deployment of your MBSE. It is important not to be afraid of this complexity, which is the “right” price to be paid in order to benefit from the significant gains made by deploying a model-based engineering process.

Authors: Joseph ARACIC and Pascal Roques

Translation credit : r’Go  Translations (Sylvie Hergault)

[2] Model Based System Engineering -  MBSE

[3] ,


[5] C. K. Ogden and I. A. Richards: The Meaning of Meaning: A Study of the Influence of Language Upon Thought and of the Science of Symbolism; London: Routledge & Kegan Paul, 1923

[6] The higher the number of objectives, the more difficult it is to develop the conceptual model.

[7] UML (Unified Modelling Language - is a graphical modelling language designed to understand and describe needs, to specify and document systems, to draft software architectures, to design solutions and to communicate points of view. UML unifies both notations and object-oriented concepts. UML is based on 14 types of diagrams, each of which is dedicated to representing the particular concepts of a software system.

[8] AADL (Architecture Analysis and Design Language) is a language used to describe the architecture of onboard systems, in particular in the automotive and aerospace sectors. This language is currently being standardised under the authority of the SAE (Society of Automotive Engineers).

[9] The Modelica object-oriented modelling language is designed to model complex systems, such as systems that include mechanical, electric, hydraulic, thermal, etc. components. It is an open language promoted by the non-profit Modelica Association (

[10] SADT (Structured Analysis and Design Technique) uses a graphical sequence of elementary boxes that can be refined top-down into other SADT models (boxes and flows). The models may be activity models (the boxes are functions and the flows are data) or data models (the opposite).

[11] A mode of representation and analysis of an automatic control system that is particularly well suited to systems that evolve sequentially and can be broken down into steps. It is derived from the mathematical model of Petri nets.

[12] The OMG (Object Management Group - is a group of industrial companies created to standardise object technologies in order to guarantee the interoperability of developments. The OMG currently has more than 800 members, including the main players in the IT industry, plus major user companies from all fields of activity.

[14] In UML and SysML, these modalities are represented by profiles.

[15] When using a tool like Sirius (

[16] See below.

[17] (see the Chapter “Method version management”)

[18] (see the Chapter “Method version management”)

Share on Facebook
Share it on Viadeo
Share on LinkedIn
Post on Twitter
Google Buzz (aka. Google Reader)

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>