hide all comments

DSM

What is the domain? - (incremental language definition) part 3

February 02, 2009 18:09:02 +0200 (EET)

Definition of the language rules (see part 2) always requires an investigation of the domain and the language use process in more detail. Now the original material does not provide these details since it is aimed to be an introduction example. Lack of these details actually shows that the DSL we have defined is not particularly domain-specific - at least not in my opinion. Why? Some reasons:

  • Lack of narrow focus. If you take a view of the metamodels (1, 2) you can see that they do not focus to any particular domain: the state machine could be used for page interaction, banking application, automotive systems or for telecom service specification in addition to the compartment control software.
  • Unclear usage process. For example, are the events unique only within a single system or should they be reused among all the systems. The latter would allow us to reuse events from a library - a likely option as the company builds different systems for different customers rather than just one. In terms of the metamodel, and DSL definition, this means: Are the four digit letters used to identify events and commands unique inside a single system or reused across multiple systems?
  • Low level of abstraction. The language focuses on a solution domain rather than on a problem domain. For example, it allows us to specify a system where the secret compartment could never be opened or systems where compartment don’t even exist. The language also asks us to define systems using four digit letters for commands and events as approaches the development from the implementation view. How about taking then a problem domain view: What if the language could guide developer and help to follow the rules of the control access system? For me that kind of language would be a true DSL a language for specifying secret compartment access systems.

This leads us back to the essentials of language design: what is the domain? Which kind of systems we are interested in developing and what are the suitable language concepts? Answering to these type of question will help us the define languages that is domain-specific, maps closer to the problem domain and thus raise the level of abstraction. This we will do in part 4.