ABOUT THIS EPISODE
Are your domain experts making many mistakes in their specifications that developers only discover much later, leading to costly rework?
Learn how Siemens Corporate Research & Technology uses JetBrains MPS to quickly and iteratively build custom engineering tools that can check specifications for errors on the fly and provide immediate feedback that the engineers can understand.
TranscriptThe transcript was slightly edited for readability.
(intro:)
Sergej: Welcome to Beyond Parsing! This podcast is dedicated to language engineering: creating custom languages and using them to develop domain-specific software tools.
Federico: We are your hosts, Federico and Sergej, two language engineering consultants. In this episode we interview Daniel Ratiu from Siemens. We discuss how Daniel used JetBrains MPS to help Siemens engineers produce specifications faster and with fewer errors.
(episode:)
Sergej: Hello Daniel, thank you for joining us on our podcast today.
Daniel: Hi Sergej, thanks for having me.
S: Ok, can you introduce yourself to our listeners? What is it you do?
D: I’m a research engineer, working with Siemens Corporate Technology. This is a central research and technology transfer department inside Siemens, it’s cross-business-unit, cross-domain. Siemens is a very large organization, each business unit has its own research, and corporate technology is on top. So basically I’m helping Siemens engineers with new technologies, especially in two directions: using language engineering and formal verification. But best combining these two technologies.
So I’m helping them with building domain-specific languages and tooling which addresses their needs.
S: And you are using JetBrains MPS to build the domain-specific languages, is that correct?
D: Yes, we are using MPS because of several reasons, and I can detail about this. The main reason is that MPS is a projectional editor and this brings several advantages over pure diagrammatical DSLs (like in Eclipse Sirius) or textual DSLs.
Domain-specific language offers domain-specific constructs but also domain-specific notations, and domain experts, like my people within Siemens with whom I’m working, are very much concerned about their notation, the notation that they use, and how they express their domain concepts.
S: Sorry, I will interrupt you here, can you maybe explain or give some examples of the languages, or of the various domains that you are using language engineering for, or building DSLs for?
D: Yes, for example, we deployed MPS, and domain-specific tooling built with MPS, to specify the configuration space of parameters of computer tomography scanners. In their domain, the domain experts, the users of the DSLs, are physicists who are non-programmers and who need to manage the enormous variation space of their tomography machines. Another example is, we’ve deployed domain-specific languages for describing technical contracts, contractual agreements between different parties. So in that domain the domain experts who are using these DSLs are bid managers, project managers, and this kind of people, who are often quite far away from the technical part.
S: What does a contract look like that they have to describe? A small example, maybe?
D: In big systems like Siemens is building they have two different parts. There’s a technical part of the system: a turbine or a train, or things like this device. And then there are contractual agreements, which Siemens enters into with the customers or the suppliers. And there’s a continuum of the offering of Siemens between the technical system and the contractual agreement and we are building DSLs which help Siemens, both Siemens technical and contractual people, to communicate easier with each other and make a better offering.
F: That’s interesting because normally someone thinks DSLs are more targeted to more technical people. But something that can be used by lawyers?
D: Exactly, so only the sky is the limit in this sense. DSLs can be deployed in most various domains. You can have DSLs which help people doing requirements engineering… Contractual agreements are nothing else but specifications, so actually a kind of requirements. You can help people doing design, or help people modelling, for example, railway tracks or any other crazy things that you might imagine.
F: Another interesting thing that you said: that makes easier, if I understand correctly, for lawyers and technical people to work together on these contracts. That is another good advantage of DSLs in general: helping collaboration.
D: Yes, this takes directly the advantage of MPS, which enables building modular and extensible languages which can be integrated with each other. So in the MPS mindset we would have languages for describing contractual agreements and languages describing aspects of technical systems, and they are integrated with each other. And then you can describe things like, for example, warranty contracts. Like, okay, we ensure warranty period, we guarantee that the system we deliver will work correctly for the next five years. And this system that we deliver has components from suppliers, for example, so we have to have warranty claims to the suppliers ensured in order to ensure back-to-back coverage of the risk. So that if the system breaks, and Siemens is not guilty, then we can have a warranty claim from the supplier.
And this type of contracts, this type of situations, already brings together contractual agreements, suppliers organization, plus the technical system, how is the system composed: which parts are bought in, which parts are Siemens parts, and how are the contracts between them.
F: I think that if someone has not worked on these large DSL families that cover a lot of different processes in an organization, it’s difficult to be aware of that. Because all the examples of DSLs you see out there, the ones that are public, are just small DSLs that are independent. While in an organization you can have this integration but the problem is that typically these things, they are inside one company. So people outside are not aware that this stuff exists.
D: Fully agree with you, Federico. Actually MPS as a meta-level technology is quite abstract and is not that much fun. It’s much more interesting when you instantiate that in a certain domain.
And this brings me to the second reason why we use MPS, why I think MPS is the best tool available. Very often, the DSLs that we build are unique. Never nobody built a DSL for this specific use case. This is why we do not have a full-fledged specification up-front of building the DSL. Actually, the process of language engineering and language development goes hand in hand with domain discovery and domain engineering, so the things are very iterative and agile. And MPS offers this possibility to quickly make a prototype of a DSL, then let domain experts play with it, and give feedback, enhance the prototype, enhance the DSL to incorporate their feedback (of course by migrating existing models because you don’t want to lose production models), and so on. So the process in our case of DSLs development is quite continuous, it’s nothing like we stop at some point. It’s the more you have, the more you want it to go on, to capture further and further aspects of your domain.
And this capability of MPS, to support the entire lifecycle of DSLs development, from language definition, with different notations, refactoring of languages, migration of existing models, testing of languages, and so on, it’s absolutely essential for this domain discovery and domain engineering aspects.
S: So what you are saying is MPS makes it possible to evolve the language somehow without losing the models. So you actually start writing the models in one language, but later, a year or two later, you actually have switched to a different language, so to speak, gradually, but the models are still with you and the data is still valid.
D: Right, precisely. But also to evolve the languages, for example, once you have a network of unit tests then you are confident in your language evolution, you get confidence that your language evolution does not break some rules that you had before, and so on. So this is this package: continuous integration, distributed development, and all that stuff goes hand in hand.
S: RIght, so we can see that you are quite convinced about the benefits of MPS. Can you maybe tell us how it all started, at Siemens, or maybe even before Siemens, how did you come in contact with MPS? What happened?
D: So I was part of the mbeddr project a long time ago, while I was working for FORTISS, this research institute in Munich, associated with the Technical University of Munich. We had an open, publicly funded project which was called “Language Workbenches for Embedded Systems” and that was a highly successful research project in which we showed that it is possible to build modular and extensible languages which can be permanently adapted to the needs of their users.
And I mean not only technically possible but also economically feasible. And the way we did that was by using MPS. So we used the capability of MPS to build these modular languages in the mbeddr project, which is basically a set of DSLs on top of C, and shown that these DSLs can be further and further specialized with new constructs, with new languages in a modular fashion, such that they address even more particular needs.
S: So basically you showed that you can build a language for safety critical systems, but not just one language, but many languages that you could compose sort of like LEGO bricks.
D: Yes, and it’s not necessarily for safety critical systems. You can use it for example for addressing platform concerns like different hardware, or having different configurations of parameters which embedded systems have. Embedded systems being cyber-physical systems, they interact a lot with the real world, with hardware, and so on, so it depends on all this kind of things, and you can capture these informal forms of data dictionaries or constant pools by using DSLs.
You can create and in this mindset use DSLs for representing requirements, for representing tests, and then you enhance the basic capability of C, which is not really supporting unit testing as first-class construct, by providing higher-level DSLs.
You can integrate the requirements, you can integrate product lines, so things which are defined in C classically with ifdefs and get very much messy, you can in MPS have first-class constructs in which you define feature models and link parts of your models with different features such that you make explicit what belongs to a certain configuration and what doesn’t.
So, I came to Siemens then with this project and Siemens is developing a commercial product based on it, called Embedded Software Designer.
S: When was this? When did you work at FORTISS and when did you come to Siemens?
D: I’m with Siemens now for more than five years. And once I came here, I started showcasing the technology, the language engineering technologies, and the possibilities also in other domains, as we spoke at the beginning. And people started realizing that actually this meta-technology is an enabler for different use cases, for a plethora of use cases in most various domains.
So it does not have anything to do with coding in special. You can code your contracts, you can code your variation space, you can code your network of railways or things like that. So it brings somehow the modern programming world to domain experts who never programmed and who desperately need languages, who need an adequate possibility to express themselves.
S: What’s their reaction to programming? Are they welcoming it or are they scared of it?
D: Their initial reaction is of surprise, because they… Software is everywhere and each expert uses for example privately smartphones and things like that and they are very much aware of what could be possibly done in software. However, they’ve never thought that it is possible to create these DSLs to address their day-to-day problems. And it’s not that they didn’t think that it’s possible, they are not convinced that it’s economically feasible. So things like, okay, you can start building your DS tooling in an incremental manner and get the first results after very few weeks of development. Such that you can evaluate and customize, continuously evaluate the benefits and the costs of building these tools. So this is what MPS makes really great. It’s somehow democratizing the landscape of tooling, with this domain-specific tooling being nothing else but functionalities around domain-specific languages.
S: So basically you can start with MPS from the bottom, without having to convince your CTO and CEO and CIO and everybody else to start the project, you can just do something for a few weeks and see if it makes sense, right?
D: Yes, precisely. And then let users decide if they want to go on or not. And actually then domain experts who are outside of computer science have a hard time taking these decisions. So my approach to this is to give demos about things which I’ve already built and to network people inside my organization such that they can share experiences with the technology. And then we start by building a prototype which shows the potential and eventually there must be an early adopter, a champion inside an organization who says “Look, I believe in this and I want to go further.” And once we find that, then this multiplicator, this person who is on the application side will make the work of dissemination and of educating domain experts much much easier because he already speaks the language of the domain experts.
S: Is this person usually a domain expert themselves?
D: Yes, in all my projects where we are successful with this approach we have at least one person who is a domain expert, who can speak the language and the problems of domain experts, such that his colleagues understand the value proposition.
And this is also my general strategy. I don’t want to have people from business units to depend on me. Actually, my goal is to enable them to build their own languages, right? DSLs is about domain-specific languages. It’s not my domain, it’s not yours, it’s theirs, people who really need it. So they need to cope with this. They need to embrace this new approach and this new mindset.
F: But does this team have developers to help them build the languages? Developers that you can train in using MPS and then take over the development of the languages?
D: Yes. So, if you have access to developers on the business side who know their business domain and can explain that to their colleagues, then it’s a very good case.
Another possibility is to, there are very often domain experts who are “computer geeks” in a sense, so people who do not program for money but they like playing around, or games, but not only games, also all sorts of Excel macros, kind of things, which are strictly speaking, very close to programming but with a very, very bad technology.
S: I think Excel is sort of programming level zero, it’s where you program without actually being aware that you are programming.
D: Right.
F: The entry-level drug to programming.
D: Yeah, and when these people see that actually they can have languages which capture their domain models, with all the good things that MPS builds, brings them: autocompletion – of course, syntax highlighting – trivial thing, different notations to have table here, text there, some picture if it makes sense, icons, or a tree.
S: I think error checking is a big benefit, right?
D: Error checking, right. In which they are prevented, using the constraints from MPS, up front, and using scoping mechanisms, they are prevented up front from making mistakes. Or when they get feedback immediately in the IDE when an inconsistency is identified. So these kinds of things are of capital importance and they are very much supported by MPS.
So my perspective over these things is that domain experts, engineers inside Siemens, they use tools, like Excel or Microsoft Word and so on, and behind each of these tools they actually create models of the thing that they are working on. But the tools themselves have no idea about the domain-specific concepts that the models contain. So basically they need better abstractions and better languages, and then, when the languages know about what domain experts want to say with their domain models, then you have much better chances for the machine to help them in their work. So for me, DSLs are not a target, they are just means, they are tools to a certain goal. So none of my projects in which I’m involved use DSLs just for specification, in the sense like UML kind of community, SysML does. We use DSLs as input for generation, for analysis, and so on. So that once you have the content digitalized, once you build the digital twin of the system using rich abstractions, then you can start automation.
S: Let me maybe summarize it to see if I got this right. So, your first point was that in the traditional tools, so to speak, people that use them, they have a mental model in their head, of their domain. But this model is not in the tool, it’s in their head.
D: Right.
S: With MPS you can bring more of that model, I don’t know if you can bring 100 % of that model, but probably a much larger part of this model you can put into the tool itself so that the tool starts understanding you better.
D: Precisely. Actually the situation is even funnier, in the sense that as long as the domain model and the domain language is not formalized, different persons, different domain experts, even colleagues, have slightly different perspectives and understandings of their domain. So it’s very interesting and funny when I’m doing language engineering with domain experts, with several in a room, and the domain experts start arguing with each other about the exact meaning of this corner case in their domain.
S: Yes, I think everyone of us has experienced at least one such situation in our work.
D: Right, and then I’m telling people “This is normal, because so far you were using semantically weak tools which allowed a lot of ambiguity, but if we want to do automation and make things machine-processable then we need to be precise.” And to my joy, most of the time, if not always, people really see a value in this concretization, in this understanding, domain engineering, domain discovery step of their work. So from my perspective building DSLs helps beside building another tool, it helps domain experts better understand their domain and clarify, formalize, and ensure consistency with each other.
S: So, basically, building a DSL that’s precise enough to be analyzed and maybe even to have code generated from it, is what helps them resolve the ambiguities, right?
D: Right.
F: And then they can debug their ideas, once they’re formalized. Because until they have DSLs they can only write some sentences in a Word document, and if they make an error that is obvious, it becomes obvious when someone tries to implement it, typically the developer. While if they have DSLs they can figure out on their own that this thing doesn’t make sense, because it doesn’t compile, it explodes, or …
D: And with the size and complexity of current systems in the broadest sense it is very difficult, if not impossible, to do this manually. So if you write a document in Word for example, Word, as you said, will catch some spelling mistakes, some grammar things, you could also use a glossary to make sure that the terminology is the same, but you will not be able to catch higher-level inconsistencies, or only very very difficult. So one of the lessons learned when you start formalizing a domain, using domain languages, is that you find inconsistencies, or gotchas, in existing documents despite the many iterations in which these documents have been manually reviewed.
F: Sometimes I think we developers think of ourselves to be smart but we have actually better tools, because think if you have to develop without a compiler pointing out errors, without tests running and telling you that you’re wrong, we make errors all day long, but we just have tools that correct us and at the end of the day we remove those errors.
D: Precisely. So a technology like MPS brings this advanced working setting with which we in software engineering or software development are very much used to, and which we take for granted, to the broadest spectrum of domain experts. So there is a potential to take programming outside from the software engineers or computer science people, and make it accessible and the mindset to the entire world.
S: I think we have spent the last 10-15 minutes very much praising MPS and domain-specific languages. I have a question that may be a bit contrarian, but have you encountered a situation where you would NOT recommend the use of DSLs or the use of MPS in particular, in your work?
D: Both of these. DSLs make sense if you are building several models, so to say, in a domain in a repeated fashion. If you are doing very unique things, you most likely don’t need DSLs which are very domain-specific to your domain. So the languages should be to a good degree reusable for the abstraction level. You could use higher-level DSLs, more abstract DSLs, such that families of use cases can be built with this.
S: So basically you need to have a family of use cases, not just one specific use case, right?
D: Right. Another situation is, I would like to make the difference between the DSL, the MPS approach with these composable languages, multiple notations, modularly extensible languages, holistic support for language development, again, from refactoring of languages, migration of models, to test-driven development for languages, integration in continuous delivery pipelines, enabling distributed development, such that I here and you guys there can develop together and integrate, or domain experts in Germany with domain experts in the States and in India or China can work together and integrate their models. So this is absolutely great and this is an enabling step which is beyond the state of practice of other modelling tools.
Now, MPS as a tool itself has different limitations. One of them is that it’s quite heavy-weighted, in the sense that if you have small DSLs you still need to deploy quite a big tool which takes several hundreds of megabytes, so 200 megs and so on, which is often too heavyweight for domain experts, especially for people who are very much end-user oriented and who are used to smartphones and things like that. This is one problem.
Another one is, you would very much like to have DSLs deployed through a web interface, such that people can hack their models in the cloud and cooperate with each other and so on. This is again, not possible today.
S: And this would probably solve the first issue, right, of the download being too big, so to speak, of the tool being too big?
D: Yes, making the tool more lightweight is a step towards web deployment.
Okay, so these kinds of pragmatic situations are still big improvement potentials for MPS. But the approach itself, the mindset of modular languages, extensible languages, “a posteriori” extensible languages, and technology stacks built around DSLs, this is a place where MPS is simply great.
S: I think it’s time for us to wrap up this episode, thank you, Dan, for coming. Do you have any closing comments or maybe something you wanted to say all this time but we didn’t let you?
D: I think we spoke a lot about the advantages of MPS and how we use it inside Siemens and how I help domain experts to make their work easier and to be more productive. I think that on the community side, the MPS community is still… maybe we shouldn’t say this…
S: You mean it’s still very small?
D: Yes, and this is actually a high risk because it makes the entire technology stack fragile in the sense that, okay, where do you get help in five years, when it’s that small? There are some other management aspects which are tricky.
S: I see, so this is another concern I guess that you are having at Siemens?
D: Actually, yes, this kind of stuff is a trickier one that you can imagine.
F: It’s also true that maybe many users of MPS just don’t say that publicly. And maybe me and Sergej experience that because we build DSLs for certain companies but then we are not allowed to say that. So we know they are using MPS, but…
D: Why? This is, to some extent, in their own interest, to say, hey, we are using it. Because this is an open-source technology. If we had it closed-source then it’s a different story. But what I’m saying and most of the things I spoke about we covered with experience papers.
S: Maybe we can formulate it as a sort of a plea to the community: if you are using MPS, don’t keep it a secret, please let people know.
F: Yeah, definitely.
S: Ok, Daniel, thank you for being here with us today, thanks again for coming.
F: It was a real pleasure.
D: Thank you for inviting me, and let’s enable domain experts pick their languages.
(outro:)
S: Thank you for listening to this episode of Beyond Parsing. We are your hosts, Federico and Sergej, two language engineering consultants.
F: If you want to learn more about domain-specific languages and language engineering, visit beyondparsing.com.
The post Interview with Daniel Ratiu appeared first on Beyond Parsing.
