Juha-Pekka on DSM

While reading again Martin Fowler’s DSL book I realized that I never published any versions of my “Gothic Security Language” – unlike I promised. While Steven Kelly already gave several practical guidelines to improve the existing state diagram language I decided to start from the scratch in order to put the domain back to the language. In other words, create a language that is focused on the problem domain.

After looking the original descriptions, like:
“Miss Grant has a secret compartment in her bedroom that is normally locked and concealed. To open it she has to close the door, open the second draw in her chest, turn her bedside light on - and then the secret panel is unlocked for her to open.“

i wanted to raise the level of abstraction as high as I saw it possible. To do that I was thinking the customer of Gothic Security Inc as a language user who could then define own ways to use secret panels. This led me to immediately abandon the use of codes like ‘DIUL’, ‘PNLK’ or ‘D2OP’. Similarly I was ready to throw away concepts like ‘State’, ‘Command’, ‘Transition target’ etc. They are not mentioned in the system description above either. What is mentioned are the domain concepts like ‘Chest’, Door’, ‘Open’, ‘Light on’ etc. that I could use directly as candidate concepts in the language. Note that when using a metamodel-based tool, MetaEdit+ in my case, I could always add ‘States’ etc. if needed. But now Miss Grant’s system as described above doesn’t need them.

To identify language concepts I conducted a domain analysis: investigated what are similarity and variability among the control access systems of Gothic Security. Note that I did not conduct a domain analysis for the state machines but to the problem domain. The input for the analysis was the three customer systems (Miss Grant, Mr G, Mr C) but we could easily extend this to look future possible needs too. Naturally the more we would have example systems the better.

The feature model below describes some of the main variability among the three systems. A control system may have an alarm action and possibly an overriding lock. There must be, however, a number of events occurring in relation to the furniture in the room to open the secret panel.

Since most variability among the systems of Miss Grant, Mr. G and Mr C are on behavior the feature models can’t be applied more than for the preliminary analysis on some variation. The variation that is most visible for the user, like order of events and the ways how the operations with the furniture etc., can’t be recognized in feature models at all.

To properly conduct domain analysis we also need to specify different control structures and how the system reacts on events occurring in different order and how it triggers actions. These are the most visible parts how the different installations vary. While analyzing the system more we see variability like:

• The order how events may occur vary
• The number of times an event is repeated varies (e.g. lights can be set on and off many times, or door can be opened and closed multiple times).
• The system can handle more than one door and the door can be located anywhere in the house.

These kind of variations we can specify in the metamodel (aka in the language specification). Some things are not completely clear to finalize the domain analysis, like how alarm actually operates (activation time, muting, shutting down) since it is difficult to find variability if there is only one case ;-) I thus focused on specifying the language to capture functionality used in Miss Grant’s system since the other systems have the similar functionality giving enough data for domain analysis.

The 2 min video below shows the language in use: how the system for Miss Grant is defined. As you can see we do not have anymore a general state machine but a Gothic Security Language. The language is now domain-specific; it raises the level of abstraction, prevents errors on creating illegal systems, and makes development faster.

The language is a result of domain analysis: creating the language from the problem domain rather than creating it from the code framework side. Now the domain is treated as the first class citizen in the language. I believe this language is more fun to use!