In previous posts we addressed what DSLs are and why they are useful and necessary in software development. Once we decided to base our development on them, we need a tool to design and use them. This tool is technically known as Language Workbench (LW).

A LW is composed of two main modules:

• Language design.
• Use of the language. Programming.

Probably, in the future, it will split into two different tools, the reason is because, inside or outside organizations, there will be two different roles: language designers and language users (programmers).

Language design
A LW provides utilities to define the different building parts of a language:

• Abstract syntax. The grammatical/conceptual structure of the language. It’s also known as meta-model.
• Concrete syntax. The human-readable representations of these concepts. They can be textual and/or graphical representations. In other words, it’s the definition of the visual interface for the developers.
• Static semantics. Define rules and restrictions that the language must conform (besides being syntactically correct).
• Dynamic semantics. It is mainly the translation into traditional languages though, as we will mention later, here resides the greatest potential of this development methodology.

Use of the language
Once the building parts are defined, the tool is able to interpret them and provide a development environment (IDE). Besides editing, depending on how sophisticated is the tool, it can provide utilities such as: code completion, static validation, syntax highlighting, different views and even debug support.

This environment will also allow us to generate the code and, sometimes, integrates the target-application building process.

Future Potential
We could sum up that this new development process is similar to the traditional one but with the benefits of DSLs and code generation, which is the huge advance argued by researchers and supporters of this methodology.

Agreeing on this, for us the great potential, yet to be discovered, is the fact that a program is no longer a set of statements but a knowledge representation. Once we define the concepts and rules, semantics may be able to offer much more services than just code generation.
 

View all Academic Posts.
 

Let’s get to the point. Here is the list:

• SW Quality: In every field: performance, reliability, security…
• Standarization: not only in source code but in user interface, database structures….
• Centralization: global policies such as error handling, exception management, data display format, data validation, permissions check, etc. are centralized on the generator. This kind of policies are also known as cross-cutting concerns and is an issue tackled by Aspect Oriented Programming (AOP) in traditional programming. Centralization avoids the issue.
• Refactoring: related to the previous benefit, code refactoring is easy an safe.
• Productivity: Lower cost and lower time-to-market (or release time).
• Analytical skills: code generation requires a deeper domain analysis before implementing the solution via the generator.
• Design Skills: requires a good architect with a wider view.
• Healthy Growth: prevents architecture degradation.
• Team Member Integration: development culture or rules induction are facilitated by code generation.
• Level of abstraction: programming in a more abstract way, besides easier to understand (is more intentional), opens the door to new features such as: unit test generation, self-documenting, data population, semantics, machine reasoning and others.

Code generation is not easy, implementing a generator requires time and effort, and even more if it’s a language workbench but, clearly, benefits are huge.
 

View all Academic Posts.