Browse Prior Art Database

Domain Specific Programming Language

IP.com Disclosure Number: IPCOM000174835D
Published in the IP.com Journal: Volume 8 Issue 10A (2008-10-13)
Included in the Prior Art Database: 2008-Oct-13
Document File: 3 page(s) / 92K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Today's programming languages are not capable of supporting scenarios of specific technical domains. For example, programming languages such as C++ or .NET are not aware of domain specific objects such as phasors, alarms, process values etc. This makes the development of solutions complicating. Programming languages such as SQL which are designed for data retrieval are only aware of tables and values. However, even these languages do not understand the meaning of technical domain specific data entries. This makes solutions that handle historical data, power quality data etc complex. The mentioned issue is depicted schematically in Figure 1. The developers need to be both, experts in the programming language and in the domain. A partial separation of concerns is not possible. This leads to the problem that customers and other experts are not able to bring in their knowledge into the systems easily, since they would have to write programs in a programming language far away from their technical domain.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Domain Specific Programming Language

Idea: Thomas Jachmann, DE-Nuremberg; Klaus Polster, DE-Nuremberg; Bernd Mitter, DE-

Nuremberg

Today's programming languages are not capable of supporting scenarios of specific technical

domains. For example, programming languages such as C++ or .NET are not aware of domain

specific objects such as phasors, alarms, process values etc. This makes the development of

solutions complicating. Programming languages such as SQL which are designed for data retrieval are

only aware of tables and values. However, even these languages do not understand the meaning of

technical domain specific data entries. This makes solutions that handle historical data, power quality

data etc complex.

The mentioned issue is depicted schematically in Figure 1. The developers need to be both, experts in

the programming language and in the domain. A partial separation of concerns is not possible. This

leads to the problem that customers and other experts are not able to bring in their knowledge into the

systems easily, since they would have to write programs in a programming language far away from

their technical domain.

At present, systems are basically built on a fixed Business Logic accessing the specific data sources.

The Business Logic is equipped with a more or less flexible User Interface. The flexibility depends on

the features and requests that are provided by the Business Logic. Therefore, the Business Logic

needs to be written by developers that are fully aware of both data access and domain specific

aspects.

To solve the problems mentioned above, a solution is proposed in the following. In this solution, the

data sources and the basic Business Logic that handles the data access are encapsulated by an

engine that is able to parse, compile and execute scripts/programs in a domain specific language.

High level Business Logic and applications can be written in the domain specific language that is

executed by the Domain Language Evaluation Engine. The engine executes the translated requests

for data storage of the particular type.

With the proposed solution, the knowledge is separated. The developer needs to provide the domain

specific language, the evaluation engine and a fast and robust access to the data sources. The

domain expert, which can be the customer as well, provides the domain knowledge in the domain

specific language.

In a practical realization, the core of the proposed solution is a domain l...