Domain specific languages for development

The idea of domain specific languages is not new to information technology. Jetbrains published a paper on language oriented programming in 2004. Martin Fowler has written about DSL's and their advantages and Markus Völter explains Model Driven Development with DSL's in detail. In the domain of business software, business rule engines and languages to model workflow systems are widespread. Especially the business process modelling language comes with comprehensive concepts to model business processes. A presentation on language-oriented business applications, which argues that business people want to express themselves but demand appropriate tools, introduces to the topic with examples. 

die modellwerkstatt provides three domain specific languages (DSL’s) to model the different aspects of business applications. The languages are tightly integrated. Thus, the languages can be stacked on top of each other, to model a whole business application seamlessly, starting with the database access,  the transformation of data via business logic and the visualisation in user interfaces. In the following three sections, we provide a brief glimpse on each language: Forms (user interface modelling), objectflow (business logic) and manmap (database mapping).

forms - a language to model user interfaces

The common user interfaces for business applications include primarily two types of data visualizations: (1) a tabular form, where a number of data objects are presented in a table with row and columns; (2) a plain form, where a number of fields are shown, oftentimes allowing users to edit values in those fields. Our forms language let application developers specify tables and forms in a logical manner by defining the columns in tables, the fields in forms, their formatting and their relation to data objects. What is additionaly needed? A layout to define more complex user interfaces! Thus, our language brings beyond tables and forms logical concepts for grid- and a tab layouts. 

(Figure 1: User Interface Specification)

The picture above shows a screenshot from the development IDE. Two forms are specified: an InvoiceForm as type FormContainer, containing a TableForm named as InvoiceTableForm. The TableForm expects a list of Invoice objects and specifies, that three properties of each Invoice are visualized as rows. The columns of the table are longtext, value and currency. The top-level FormContainer is merely for layout purpose.

Clearly, this is only an illustrative example. User interfaces get more complicated, when supporting complex business process. Nonetheless, the forms language is capable to handle those specifications in a pure logical way, without any need to rely on java programming or any specific ui-toolkit. The specifications are not only easier to read, but the user interfaces are easier to maintain and change during their lifecycle.

objectflow - a language to specify business logic

The business logic encodes the rules of the real world business and therefore how data can be created, displayed stored and changed. Our objectflow language brings in three important concept, to model business logic, namely the entity, commands and processes.

Generally speaking, entities are data objects which do have properties to store values in. One of the most important decision to be made when writing business software is on the properties and objects necessary to support a business process adequately. Objectflow allows modelling data structures in a tabular form, covering also meta information on properties, like range or length. The short- and long-description of properties are the default labels displayed in user interfaces. This tabular presentation is easy to read and can serve as documentation also.

(Figure 2: Specification of an Entity) 

Any behavioural aspect of business software has to be modelled in commands. A command is the very concept in our language where data is transformed or calculated, is it a sum over invoice positions or adding and removing positions to an invoice. What is important though is that commands can be executed successfully or not at all. They follow a transactional logic which can not be executed halfway only.

The third important concept of objectflow is the process. We expect every business process having multiple states it can be in. For example, "finished", "waiting for approval" or "check by clerk" are viable states for process in the objectflow language. Given that all commands do belong to a process, one of the major functions of processes is to define, which commands are available in which states. Specific commands might be available in particular states only. Furthermore, a process defines how to transit from one state to another, most often by executing a specific command successfully.

The domain specific language objectflow is used to model business pcesses and their behavioural aspects, as well as data structures necessary. They are modelled in a pure logical way without referencing any particular runtime environment or technology. The concepts introduced above are unique to the business software domain and structure applications clearly, improving long term readability and software maintenance.

manmap - a DSL for database access

Accessing the database, retrieving and storing data, is another crucial domain of business applications. Relational database systems and SQL are most well known across the industry for years. While there are myriads of tools available for accessing databases in java, all come with certain drawbacks and complexity. It is still not uncommon, to access them in plain SQL and map result tables back to java objects. Although mapping is in its nature a very technical computer-domain, a tailored language can simplify matters dramatically.

Our manmap language defines a “save” statement to store objects to databases and queries to retrieve them easily. But before using those statements, a mapping between java objects (or objectflow entities) and database tables has to be modelled. The following figure shows a simple mapping for the Invoice entity already introduced above. The notation is easy to read and more compact than any xml description. 

(Figure 3: Invoice Mapping)

Queries in the manmap language almost come simpler. The first method below saves a data object to the database, the second one does not only load an invoice but also loads all invoice positions. While it is unambiguously specified, how and in which sequence data should be retrieved, any technical details are hidden and separated from business applications code.

(Figure 4: manmap queries)

Business application developers can easily retrieve and store data objects to sql databases by means of the manmap language. No further libraries or toolkits are needed, minimising dependencies and complexity.

This short introduction to the three languages for business application modelling should give you an idea of separation, structuration and ease of use. Feel free to contact us on further information or more specific questions. Applications for demonstration purpose are also available.

Contact us: