Karel De Vlaminck

Agility in the avionics software world

This paper takes a look at how XP and other agile practices can improve a software process for the development of avionics software. Developers of mission critical airborne software are heavily constrained by the RTCA DO-178B regulations [8]. These regulations impose strict rules regarding traceability and documentation that make it extremely hard to employ an iterative software development process. In particular, the extra validation overhead increases the time spent on small iteration cycles (for example, a bug-fix) to several weeks. Currently, this sector is also pressed to switch to a more agile, customer driven approach. In this paper we investigate how to speed up development and cope with changing requirements using agile techniques. The research was carried out in cooperation with Barco, a major Belgian avionics equipment supplier. We explain why certain agile techniques have less effect as the project progresses. We point out the stadia in which each XP practice is beneficial and where XP practices might cause a slowdown.

Polyvariant constructor specialisation

In his PEPM’93 paper Mogensen introduced a new off-line specialisation technique, constructor specialisation. What differentiates constructor specialisation from conventiomd specialisation techniques is the ability to specialise constructors. Like functions, constructors are specialised with respect to their static arguments. As these constructors are also part of a program’s type declaration, the effect of constructor specialisation is no longer limited to the algorithmic part of a program. Specializing constructors requires introducing new type definitions, specialised variants of the original definitions. The effect of constructor specialisation is, therefore, best understood as a combination of specialisation and a retyping transformation (changing the types of a program). In this paper we develop a new constructor specialiser that solves some of the remaining problems in [Mog93]. Moreover, we show that this specialiser provides an alternative solution for a problem in [Lau91b], where a mix-style [JSS89] specialiser failed to remove the projection-injection overhead from specialised versions of the specialiser.

The ELL(1) parser generator and the error recovery mechanism

SummaryA syntactic error recovery technique is presented that is simple and at the same time very powerful. It has the main property that it is phrase marker oriented, where phrase markers are considered symbols delimiting language constructions, e.g., begin and end for blocks, (and) for expressions, and [and] for indices. The basic idea of this error recovery technique originates from P. Branquart and has been worked out in the Algol 68 compiler project, see [8] and [9]. Here, we are especially concerned with the generation aspects of error recovery. In particular, it is investigated how error recovery can be mechanised in an ELL(1) and LALR(1) syntax directed translation scheme and which conditions the syntax must satisfy. Both the ELL(1) and LALR(1) generators are implemented and are part of the system LILA: a Language Implementation LAboratory [28, 29, 30]. Only the ELL(1) generator is described here.

Timing driven architectural adaptation

Self-adaptation is currently addressed in general frameworks and reference architectures but not in the application architecture. This paper defines concrete concepts to specify timing driven self-adaptation in the software architecture. This self-adaptation is aimed at high-end embedded component based applications. We create an architectural view of a music application describing this kind of adaptation and discuss its implementation. The novelty of our approach is the definition of separate constructs for the monitoring, the adaptation decision logic and the adaptation itself. This allows independent specification of policy and mechanisms and the possibility to adapt other applications in order to satisfy important constraints. The implementation itself consists of reusable run-time counterparts of the constructs. These counterparts are managed by the component middleware and configured by the architectural specification. This way one does not need to write additional self-adaptation code.

Visto: a more declarative GUI framework

By inverting the widget — call back relationship and by providing selectors, a suitable abstraction for concrete widget choices, Visto provides a more declarative approach to defining user interfaces, building on the declarativeness of the lazy functional language Haskell.

SLS/1: A Translator Writing System

The translator writing system in its didactic version is an ideal tool upon which a course on compiler construction can be based. The student can treat non-trivial examples in a flexible and modular way within a reasonable limit of time [16]. This version is implemented in PL/I on the IBM 370 model 158 under OS.

A GUI on top of a functional language (poster)

Functional programming has proved to be an uttermost declarative methodology. It focuses on the what and not on the how. Aleo 1/0 can be successfully expressed in FP, although rumour has it that none of the functional 1/0 systems really work as elegant aa functional languages can. In the field of graphical user interfaces (GUI), impressive results have been achieved. Two different but major milestones are the Fudgets library [1] in Haskell and the Clean 1/0 system [2]. Despite the fact that they are really successful, both systems suffer from the fact that they are not aa declarative aa could be, because they concentrate too much on the how. They require the programmer to first choose the actual form of the interface. This describes how the action is triggered, not what action. Only after the programmer has defined f,e. the button, can he attach functionality to it. Notice also that the application code must be attached to the button spectically. This means that changing from a button to a menu item mav incorporate suite some work: . . . the definition and type of the attached function may change or may be attached in a different way. This is too much focus on the how on the appearance of the widget. In ‘Selectors: going beyond user-interface widgets’ [3] Jeff Johnson describes how each element of a user interface serves one of two purposes: either to select data, or to select commands, e.g. a pull down menu can be used to start a command, such aa load and save, or also as a way ta limit the input possibtities for the user. This is the point we are really interested in: are we selecting commands or data (and what data)? Whether this ia dane through a pull dawn menu or a button list is irrelevant. The actual vieu al appearance is only part of the how. The observed division in data and command selectors is particularly applicable in imperative languages, because there a certain variable can be easily connected to a widget. And when the widget is selected, the contents of that variable will be (destructively) updated. Despite the fact that (pure) functional languages do not allaw such side effects. we believe that this can be accomplished by the use of state transition functians. The paster will present work in progress regarding the implementation of such ‘selectors’ using both Fudgets and Clean 1/0. Work

A Debugger for a Meta-IV-like Meta-Language

The purpose of this paper is to report on the development of a debugging tool for a Meta-IV-like language. The tool consists of a static semantics checker and a debugger. The meta-language includes a subset of the DDC Meta-IV language, but with some simplifications and enhancements. A strong typing system was added to improve the static semantics checker. The debugger itself is quite powerful and includes features allowing (for example) invariants to be attached to breakpoints, objects and types. This paper explains why the debugger was developed, gives a short overview of the meta-language by comparing it to DDC Meta-IV, and presents some important features of the debugger.