Is SysML too complicated? And if so, what is the alternative?
When it comes to modeling languages, the reaction of people is often extreme: there are people for whom models are far too complicated; then there are those who like to work with diagrams and perceive them as the model; and those who understand the modeling languages in depth and build correspondingly complex models that are impressive, but are hardly understood by anyone and are therefore ignored.
This situation makes it difficult to work with models and to get all stakeholders on board at the same time. That is a pity, because You can do an incredible amount with models. And models also enable more agile working and better reaction to changes. But what use is this if the models are rejected by a rejected by the majority of stakeholders? Even if good document document generation and training?
I already pointed out in the past that even a modern requirements tool models. If we have different entities (different requirement types) with relationships, then we have a Entity relationship model (ER). And employees can handle a modern development platform such as Jama or gitHub in a short space of time.
The language for entity-relationship models has only three language elements: entities, relationships and attributes
In practice, many users are not even aware of this. They only know that there is a data or information model in their working environment.
However, the difference between the language for an ER model and a language such as UML or SysML is huge: in the ER model, there are actually only three language elements: entities, relationships and attributes, which can be visualized in a diagram type. In contrast, UML has 13 diagram types and hundreds of element types, and SysML is similar.
Is there a middle way?
ER modeling is widespread (even if many users are not aware of this). And even if UML and SysML have established themselves as standardized languages, the user group is still significantly smaller. And in particular, it is often only the specialists who do the modeling, not all stakeholders.
Hence the question: Would modeling be more successful if the modeling language were not so complicated? In all probability, the answer is yes. There are also various approaches in this direction, for example:
- Use limited language scope - With UML and SysML in particular, it is common to use only a small part of the language elements.
- Profiling - This is supported by UML and SysML in order to adapt them to specific areas of application
- Domain-specific language - One step further is to develop your own modeling language that picks up on the language of the stakeholders.
- Other languages - In addition to UML and SysML, there are many other general and specialized languages, such as FMC, ROOM or BPMN.
UML and SysML have two enormous advantages: Firstly, they are supported by several (!) commercial tools, and secondly, they are taught at universities.
Other languages are also taught, of course, and there is at least one editor for almost every language - often free or open source. However, no other language comes close to the critical mass that UML and SysML now have, at least for the time being.
How do we achieve more modeling?
My answer to this question is: we need to make the added value of modeling more obvious and improve the cost-benefit ratio of modeling. At the end of the day, it's the result that counts. But in order to achieve a positive result today, a great deal must first be invested in knowledge, experience, tools and processes.
Furthermore, it is one thing to have a language, another to be able to use it. Choosing the right approach is not that easy. I have already presented the (not very widespread) ICONIX, which works with a subset of UML works. Dassault (formerly No Magic/MagicDraw) has its own method for working with SysML, MagicGrid. A similar approach is taken by Thales, which not only has a open source tool (Capella), but also a method (Arcadia).
But of the approaches listed above, which is the most effective? Other languages, such as FMCare also used in industry. Profiling and restricting the vocabulary of UML and SysML is already being practiced today. And even if the creation of domain-specific languages is time-consuming, it is much easier today than it was five years ago.
What is your opinion? In which direction is the development heading? Feel free to discuss in the comments!
Image source: Capella
