Next big step, building my own modeling tools. Let's blog again!
I have a so many ideas I would like to write about, but it is difficult to find the time to really do my ideas justice. Therefore, I decided to focus myself more on development then writing.
Shortly after my previous blog post I made a start with my first prototype for the home automation DSL for which I decided to use MetaEdit+. I do have to confess that this was the first time I really made use of MetaEdit+. However I do not regret spending my time on getting used with it. In other words, I am impressed by how quick I got my self familiarized with the tooling (only a matter of hours). The concept MetaEdit+ uses to store models is in line with what I expect from a language workbench. Objects, properties and relations are well separated and offer the flexibility needed during the design process of a language. You can modify the language without the need to regenerate a document model or the visual representation of it.
However, from the usability perspective I still see room for improvements. MetaEdit+ is definitely one of the more intuitive and flexible domain modeling tools. Nevertheless, the user still has to get used to concepts as languages, visualizations and models. From a technical perspective I really prefer this clear distinguish, but for domain experts who would like to create models without being forced to use a language pre-defined by others it might be interesting to make this as transparent as possible.
After seeing and working with tools like the Microsoft DSL Tools, Microsoft SQL Modeling, MetaCase MetaEdit+, MetaEnvironment (CWI) and Intentional Software, the conclusion is that they all have some overlap in concepts, but are unique in their own way. Some tools are more focused on academic people with knowledge about formal languages, others on developers creating frameworks. But in all the tools I am missing something and that is the focus on domain experts and collaboration between people with different kind of expertise.
For the most part language workbenches seem to follow a process, where as the first step a language has to be designed, then a visual representation and then the models. Before a domain expert is able to define its models someone with knowledge of designing languages should be involved. In some cases, languages and visual representations even have to be compiled and distributed by installation packages before they can be used. This might be no issue when these tools are used in combination with existing software frameworks. A very good example of a successful DSL is the ACA.NET Service Factory from Avanade, build using the DSL Tools from Microsoft. ACA.NET Service Factory is build for a technical domain, meant to be used by developers and to be used at multiple projects to pay back the investment. The DSLs in this case are quite stable, so not using dynamic modeling tools is not a big issue.
The less flexible a DSL tooling will be, the more time it will take to develop a specific version of a DSL. In my opinion, this will become an issue on projects where custom build DSLs are a key element of the requirements engineering and development process and constantly subject of changes. But how can we make DSM more interesting for to be used in crucial parts of projects where the domain is not clear yet?
In practice, domain experts within companies already created their own languages. They use applications like Excel to write down business roles. One example I have are the medical acceptance procedure from my Masters thesis. The medical advisor used Excell sheets. These sheets had columns to refer to other questions depending on the answers given and columns with values for calculating risks. The sheets however could not be used as input for generating code.
I am working on a concept that will follow different process of designing languages then currently used when working with other language workbenches. In my concept models are used as a starting point rather than a language design. The first prototype I am creating will definitely support tables, graphs and forms but might also include for example flows and trees in future versions. The first step by the user will be to choose a visualization form it thinks will be suitable to express its thoughts, for example a table. The user then puts the data into the table. When it adds columns, it is has to name them. By doing this, the user is creating a language.
The previous months I have worked on a prototype. The results so far are, despite of a lot of concessions I had to made, very promising. Building a graph tool using WPF (Windows Presentation Foundation) is one of the biggest challenges I am currently focusing on, but will result in a interactive experience for the end user. In the coming months I intend to post about my experiences with WPF and post more details about the design of my prototype.