Little languages: little maintenance?

Arie van Deursen, Paul Klint. Little languages: little maintenance?. Journal of Software Maintenance, 10(2):75-92, 1998. [doi]

Review: Little Languages, little maintenance?

Posted by Ricky T. Lindeman on 30/06/2010 16:19, last updated on 30/06/2010 16:27 (Public)

“Little Languages, little maintenance?”

Title: Little Languages, little maintenance?

Authors: Deursen, Arie van and Klint, Paul

Review and Summary

The question mark in the title suggests that the statement that “little languages require little maintenance” is questionable. The paper will make it clear that little languages are indeed hard to maintain based on experience taken from the industrial practice.

In the introduction section of the paper some terminology is explained that will be used as well as the goal of the paper. The abbreviations DSD (Domain- Specific Description), a program written in a DSL, and DSP, a software tool that transforms a DSD to an executable form, are not found in more current lit- erature. Using a DSL should decrease maintenance costs when a domain-expert can directly use the DSL to make changes to the DSL program, namely due to the readability of the DSL. However the authors identified a big disadvan- tage when the underlying structure of the DSL has to be changed, generating a huge negative impact on the software maintenance costs. Therefore the goal of the authors is to “elaborate on the advantages and problems of the use of domain-specific languages, emphasizing their role in software maintenance”.

The structure of the paper is as follows: section 2 discusses an example DSL taken from the area of financial engineering. Section 3 covers the implications for software maintenance, and identifies the risks and opportunities involved in the use of a DSL. Section 4 and section 5 describe two techniques that will help address two of the potential problems found.

Section 2 describes an application in the financial domain based on dealing interest rate products. Adding a new product was difficult leading to long time- to-market for new products and it was impossible to verify the implementation of the software engineer against the instructions given by the financial engineer making it unable to detect incorrect behavior before-hand. To solve these prob- lems a DSL, called RISLA, was implemented. Because the original program was

written in COBOL and used a large library written in COBOL, programs writ- ten in RISLA are translated to COBOL providing an abstract layer on top of the library. The RISLA language evolved and eventually a new DSL, Modular RISLA, was built on top of RISLA making the generation of RISLA code easier. And finally, an inter-active questionnaire interface was built on top of that to make the language more accessible for the end-users.

The authors evaluated the project and came to the following conclusion: Time to introduce a new product was decreased and validating correctness of the products had become easier. However the project had one major drawback concerning software maintenance. Whenever new features had to be added, the language had to be extended. This was not an easy operation as it requires compiler construction skills that were often not present under engineers with a COBOL background.

Section 3 focuses on the maintenance perspective of DSL’s. In the first part the authors lists well-known general benefits of using DSL’s and discuss the DSL development process. Research by Kieburtz et al. suggests there is empirical evidence that using DSL’s increases flexibility, productivity, reliability, and usability resulting in lower costs [4]. The DSL development process as listed in a newer paper from Deursen et al. [3] is based on the findings in this paper, whereas this paper based its steps on Cleaveland [2]. However, in this paper the authors do not propose a grouping of development steps as was done in their newer paper. The first part ends with a discussion of domain analysis strategies. An import factor impacting software maintenance costs that can be identified when analyzing the domain is the variability of the domain. A domain with many modifications will require more maintenance.

The second part of section 3 focuses on the software maintenance aspects in the design step of the DSL development process. Several considerations have to be taken into account that will eventually have their effect on the software maintenance costs. The questions are based on functional requirements but also on non-functional requirements such as the technical background of the DSL programmer. The authors mention that the trade-offs depend on the domain and application, and on the importance the maintenance aspect is considered during development. The authors do not provide any empirical evidence or case studies to show situations in which the maintenance aspect is not important during the development phase.

In the third part the authors introduce the term “maintainability factors”. These maintainability factors have an effect on the costs per modification re- quest. When the expected costs per modification request are low, the software has a high maintainability. The authors present a table listing several main- tainability factors and for each factor they indicate the influence in the case of DSL’s. The authors mention that the factors are mostly taken from other papers [24, 23, 22], but do not mention their selection criteria. For instance, the experience of the maintainers team is mentioned as a factor but is not listed in the table. Also not all DSL influences (ranging from negative via neutral to positive) are motivated. Furthermore, it seems that the authors determined the DSL influence on these factors when DSD’s (DSL applications) are main- tained, while previous sections discussed the maintenance of the DSP. But also the type of the modification has has an effect on the DSL influence. The ISO standard on software maintenance [1] lists two classifications of maintenance: corrections and enhancements. Enhancements to the DSP have a negative effect on the maintainability, because the maintenance staff requires skill in language design and language implementation techniques. Correcting errors in the DSP would have a less negative effect, because often no design decisions have to be made. Enhancements and corrections on a DSD however have a positive impact on the maintainability factors, because domain engineers can often make these modifications themselves.

The last part of section 3 lists several other risks that are not related to the design phase. In the remainder of the paper the authors discuss two techniques to alleviate the following two risks:

  • Instead of a single application written in a GPL, three applications have to be maintained: (1) DSD’s, (2) DSP’s and (3) the library implementing
  • the domain logic. Related, but different, application area’s have different DSL’s and often these applications need to cooperate.

Section 4 discusses the ASF+SDF Meta-Environment and how it supports the development and maintenance of application languages. The authors men- tion that this was also used in the design of the RISLA language. ASF+SDF allows the DSL designer to describe a DSL in a formal language and auto- matically derive support tools from these descriptions. Using ASF+SDF the DSL designer can describe the (1) context free grammar, (2) context sensitive requirements, (3) transformations or optimizations, (4) operational semantics, and (5) translation to target language. The Meta-Environment turns these into a parser, type checker, optimizer, interpreter, and compiler, respectively. Cre- ating a complete language definition can be seen as an extra investment during the design phase, but it positively effects the maintainability of the DSL when DSL support tools come for free.

Section 5 introduces the TOOLBUS architecture that allows heterogeneous, distributed, software components to coordinate with each other. TOOLBUS for- bids direct inter-tool communication, as all communication between the com- ponents are controlled by a “T script” formalizing all the desired interaction among tools. An adapter can be needed to transform the data output from a component to a format that is compatible with the TOOLBUS. When this ar- chitecture is applied to DSL’s, each component is a DSL compiler. With respect to software maintenance the following advantages can be identified:

  • The TOOLBUS is “middleware” and can connect new and old software components, enabling a gradual transition from a traditional component based system to a DSL component based system.
  • Maintenance of a DSL does not affect the whole system.
  • Different DSL’s can internally use different technology.
  • For flexibility and ease of maintenance, each DSL compiler can also be based on a private TOOLBUS.

Conclusion

The paper provides an extensive list with software maintenance issues that could arise when maintaining a DSL. Most of these issues can be dealt with in the design and implementation phases. However the authors miss to discuss issues that are relevant in the actual maintenance phase, in particular when enhancing the DSP: When existing DSL programs and domain specific data are present and the underlying domain model changes, how can the developer ensure proper data migration and unchanged behavior for existing DSL programs? A solution commonly used in GPL programs would be to write unit tests capturing the behavior of the DSL before performing the maintenance. Unfortunately it is often impossible to catch all behavior because of limited resources, be it time or money.

References

[1] ISO/IEC 14764:2006 software engineering – software life cycle processes – maintenance. Technical report, 2006.

[2] J. Craig Cleaveland. Building application generators. IEEE Softw., 5(4):25– 33, 1988.

[3] Arie van Deursen, Paul Klint, and Joost Visser. Domain-specific languages: An annotated bibliography. SIGPLAN Notices, 35(6):26–36, 2000.

[4] Richard B. Kieburtz, Laura McKinney, Jeffrey M. Bell, James Hook, Alex Kotov, Jeffrey Lewis, Dino P. Oliva, Tim Sheard, Ira Smith, and Lisa Wal- ton. A software engineering experiment in software component generation. In ICSE ’96: Proceedings of the 18th international conference on Software engineering, pages 542–552, Washington, DC, USA, 1996. IEEE Computer Society.

[5] Paul Oman and Jack Hagemeister. Construction and testing of polynomials predicting software maintainability. J. Syst. Softw., 24(3):251–266, 1994.

[6] D Peercy. Improving the maintainability of software book review. Journal of Software Maintenance, 8:345–356, 1996.

[7] Thomas M. Pigoski. Practical Software Maintenance: Best Practices for Managing Your Software Investment. John Wiley & Sons, Inc., New York, NY, USA, 1996.