Evolving Domain-Specific Languages

When designing domain-specific languages (DSL), the most critical choice is the selection of concepts that form the basis of the language. Sometimes concepts for the language come from the customer directly or from domain traditions. Sometimes the DSL developers force customers to use what they are already familiar with. Implementing these concepts in the DSL as close to the domain as possible is usually a good choice so the language will be readily understood by domain experts. However, instead of sticking to the existing domain concepts, it is also possible to evolve domain concepts by designing higher-level concepts based on existing concepts. In this article, I’ll demonstrate how such an evolution could be done using a classic state machine language as an example.

State Machine Language

Martin Fowler wrote a classic book called “Domain-Specific Languages.” This is a really good book, and I recommended reading it if you have plans to go into DSL design. The state machine sample from that book is copied from an article, and a lot of DSL framework developers and language workbench developers demonstrate the capabilities of their tools based on this state machine language. This language has become a kind of a DSL tool benchmark language. The sample is in the following code block (one of many variants. I've tried to compare to the one that is implemented for Xtext version of the language at the blog post by Sven Efftinge, “Martin Fowler's State Machine DSL with Xtext 2.3”):

Using State Machines to Write Bug-Free Code

The first time you heard of a state machine, what did you think it was? I thought it was a debugger. A debugger I could use to find those annoying bugs in my code. A state machine is not a debugger. However, when you master how to use a state machine, the code you write would be on the bug-free side.

What Is a State Machine?

A state machine is an abstract concept that defines and plans the stages and transitions of an application. The application only transitions upon the occurrence of an event. A state machine indicates the initial state of an app, for example, and what would be the next stage - transition - if a user uses the app.

The TodoMVC Revisited

The TodoMVC UI (todomvc.com) application is widely considered to be the "Hello World" for UI development. The site has several demos using various frontend technologies. In this article, I explore the use of a state machine for the development of the TodoMVC UI application. I'll use the vanilla JavaScript to illustrate these concepts, and I'll use the state machine framework that I presented in a previous article.

State Transitions

The first step in using the state machine is to write the state transitions for the UI of our application. I'll assume the following state transitions for the TodoMVC app (screen capture is at the bottom of the page) that I am considering here:

A Non-Blocking State Machine

Learn more about non-blocking state machines in this quick post!

In a previous article, I presented a simple state machine for Spring Boot projects. I mentioned that the framework is easy to customize for new requirements. In this article, I illustrate the customization of the framework for a situation where one or more processors need to be non-blocking.

Graphical State Machines for Java Development With YAKINDU Statechart Tools

Learn more about graphical state machines for Java development.

Have you ever looked at your code and realized that it is actually a state machine that you are trying to implement? Usually, you would start using switch-case statements or go for the state pattern approach. For larger state machines, this approach quickly gets hard to read and maintain.

YAKINDU Statechart Tools comes with a graphical editor to model your statechart and generates the corresponding Java code automatically for you. Even better, you can use Java code directly in the graphical model. In this article, I will demonstrate what this looks like and what is possible.

A Simple State Machine for Spring Boot Projects

There are many articles and open-source projects on state machines (Ref#1) that can be searched on Google or GitHub. The Spring team itself provides a state machine framework (Ref#2). However, I found these frameworks not easy to customize. Furthermore, it was not easy to add logs and throw custom exceptions where I needed. So I created a simple implementation of the state machine that can be easily integrated into Spring Boot applications. 

The idea of a state machine is to define a set of state transitions where each transition is affected by an event. For instance, Wikipedia has an example for a turnstile that has the Locked and Unlocked states, which are affected by the events "coin" and "push". The turnstile's state transitions from Locked to Unlocked when the "coin" event happens. It transitions from Unlocked to Locked when a "push" event happens. The state machine enforces that when the turnstile is in the Locked state the "push" event has no effect. Similarly, when the turnstile is in the Unlocked state the "coin" event has no effect.