hide all comments


On extending modeling languages based on user feedback

March 03, 2014 16:17:57 +0200 (EET)

Based on my experience, often the best ideas for the language and generators come when trying them out in typical development cases - in contrast to initial language definition (aka creating plain metamodel). By best I mean what language users appreciate the most. This lesson got recently confirmed again when working with a relatively large modeling language. By large I mean that the number of types (metamodel elements) is close to the number of types in languages like SysML or UML.

With this language case, there are in fact many different sub-languages and different engineers are interested in working on certain views and sublanguages only (e.g. Hardware, Functions, Timing, Events, Features, Failure behavior etc.). In fact, I can't see that a single engineer would really need all the parts of the language for his job. Still, for this domain in automotive, it is obvious to support collaboration among team members and provide integration among various views and sublanguages.

To give an example, we (2 language engineers) had defined modeling support to specify, check, and view allocations among functions and hardware. Usually both of these are graphical models, but for allocations some people prefer to have diagrams and others matrix. With MetaEdit+ we then support both and have various checking there (like that the same function is not allocated several times) along with generators (like for AUTOSAR style runnables etc). Later when the language was used with a bigger case it was told to us that a good way would be to illustrate directly in HW architecture the functions been allocated. We never had thought about that - nor the original language spec - but after 30 minutes work with the example we had to agree: makes a lot of sense and nicely illustrates graphically the integration of different views! See screenshot below showing HW components and how various logical functions are been allocated. This visualization support can be turned on/off as needed

visualizing allocation

Things obviously didn't stop here as we tested immediately also options to hide the ports when showing allocations so that the graphical model would show only that part of information that is considered relevant: allocations. Now having used this visualization support to meet language users' needs, we could do the similar visualizations for all other parts of the language, like show features been realized in a function, show all functions that satisfy a given requirement, safety cases been covered per function etc. Rather than rushing back to edit the language definition (metamodel) in MetaEdit+ we stopped and wanted to follow our experience: let's first see what kind of visualization aids/views are needed in practical work and then provide support for those. In other words, let's build the language based on the needs of the practice - not on what all could be done. The particular nice part of MetaEdit+ is that you can define the languages while they are been used and already existing models update to the new language version and features ... just like in the above case of visualizing function allocations in HW architecture.