My favorite editor anywhere

How can off-the-shelf editors be reused in applications that need mature editing support? We describe our editor multiplexer which enables interactive, application guided editing sessions using e.g. GNU Emacs and Vim. At a cost of less than 1 KLOC of editor specific glue code, both IDE builders and users benefit. Rapid integration of existing editors reduces application development cost, and users are not confronted with yet another foreign editor with its own learning curv

Deriving tolerant grammars from a base-line grammar

A grammar-based approach to tool development in re- and reverse engineering promises precise structure awareness, but it is problematic in two respects. Firstly, it is a considerable up-front investment to obtain a grammar for a relevant language or cocktail of languages. Existing work on grammar recovery addresses this concern to some extent. Secondly, it is often not feasible to insist on a precise grammar, e.g., when different dialects need to be covered. This calls for tolerant grammars. In this paper, we provide a well-engineered approach to the derivation of tolerant grammars, which is based on previous work on error recovery, fuzzy parsing, and island grammars. The technology of this paper has been used in a complex Cobol restructuring project on several millions of lines of code in different Cobol dialects. Our approach is founded on an approximation relation between a tolerant grammar and a base-line grammar which serves as a point of reference. Thereby, we avoid false positives and false negatives when parsing constructs of interest in a tolerant mode. Our approach accomplishes the effective derivation of a tolerant grammar from the syntactical structure that is relevant for a certain re- or reverse engineering tool. To this end, the productions for the constructs of interest are reused from the base-line grammar together with further productions that are needed for completion

Perinnejärjestelmien määritys ja niiden ongelmat organisaatioissa

Tiivistelmä. Tietojärjestelmät ovat nykyaikaisten yritysten liiketoiminnan edellytys. Usein nämä liiketoiminnalle kriittiset järjestelmät on kehitetty kymmeniä vuosia sitten. Järjestelmille on tyypillistä niiden aiheuttamat ongelmat niin järjestelmän kehityksessä, ylläpidossa kuin itse organisaatioissa. Jotta järjestelmä vastaisi organisaation kasvavia liiketoimintavaatimuksia, on järjestelmää päivitetään jatkuvasti. Nämä toistuvat muutokset kuitenkin lisäävät kumulatiivisesti järjestelmän monimutkaisuutta. Tällaisia järjestelmiä kutsutaan perinnejärjestelmiksi. Tämän tutkielman tarkoituksena on selvittää, miten perinnejärjestelmä määritellään ja minkälaisia ongelmia se tuo eri organisaatioissa. Kirjallisuuskatsauksen pohjalta löydettiin neljä yhteinäistä perinnejärjestelmän ominaisuutta: Järjestelmä on joustamaton, kooltaan suuri, iältään vanha, ja sen täytyy olla liiketoiminnallisesti kriittinen järjestelmä. Perinnejärjestelmiä on vaikea, ja joissain tapauksissa jopa mahdontonta, jatkokehittää. Huono jatkokehitettävyys johtuu koodikannan laajuudesta ja huonosta dokumentaatiosta. Vuosien aikana järjestelmässä on työskennellyt usea eri ylläpitäjä käyttäen erilaisia ohjelmointimalleja ja käytänteitä. Kun tarvittavat yhdenmukaisuutta parantavat refaktoroinnit on jätetty tekemättä, on järjestelmässä ohjelmointikäytänteitä useilta eri vuosikymmeniltä. Dokumentaation puuttuessa tiettyjä toiminnallisuuksia on saatettu toistaa useisiin eri kohtiin lähdekoodissa, mikä entisestään huonontaa jatkokehitettävyyttä. Tutkielma on toteutettu systemaattisena kirjallisuuskatsauksena

Large-scale semi-automated migration of legacy C/C++ test code

This is an industrial experience report on a large semi-automated migration of legacy test code in C and C++. The particular migration was enabled by automating most of the maintenance steps. Without automation this particular large-scale migration would not have been conducted, due to the risks involved in manual maintenance (risk of introducing errors, risk of unexpected rework, and loss of productivity). We describe and evaluate the method of automation we used on this real-world case. The benefits were that by automating analysis, we could make sure that we understand all the relevant details for the envisioned maintenance, without having to manually read and check our theories. Furthermore, by automating transformations we could reiterate and improve over complex and large scale source code updates, until they were “just right.” The drawbacks were that, first, we have had to learn new metaprogramming skills. Second, our automation scripts are not readily reusable for other contexts; they were necessarily developed for this ad-hoc maintenance task. Our analysis shows that automated software maintenance as compared to the (hypothetical) manual alternative method seems to be better both in terms of avoiding mistakes and avoiding rework because of such mistakes. It seems that necessary and beneficial source code maintenance need not to be avoided, if software engineers are enabled to create bespoke (and ad-hoc) analysis and transformation tools to support it