7 Problems to be tackled

In this section, I present two lists. The first list contains enumerated subproblems and the second list proposes actions of how to deal with them. The numbers of subproblems and proposed actions match.

P1

There exist already precise and powerful description formalism. The problem is that there are many of them. What has to be focused on is to isolate the common features of them and compare their expressive power.

P2

Having a precise formalism is not sufficient. Practical small and large projects of model character have to be carried out. Such examples projects have to be communicated effectively.

P3

A widely distributed problem is the asymmetric perception of development contracts coined by the asymmetric nature of subroutine calls. The caller is the master and the callee is the slave. Rooted in a long tradition of not accepting upcalls, libraries only offer functionality and do not demand functionality from the user - and if they demand, then they do not state it in the documentation.

P4

There exists an ignorance of practitioners (and researchers) against mathematical aspects of notations. The relevant bits of mathematics are unknown or poorly understood.

P5

The community of C,C++, and Java programmers seem to have missed the significant step of introducing modules. The step from Pascal to Modula has not found much appreciation and only finds acceptance in the realm of component-based systems.

A1

My work has been influenced by papers of America and Liskov & Wing and my draft paper [Heu97b] was an attempt to bridge the gap. There is a good possibility to combine the efforts of the refinement calculus community and the behavioral subtyping community. Another candidate is the theory of object by Abadi & Cardelli.

A2

I am working on a refinement tool, which itself is a project that gives material for a case study. The examples treated by the tool are small and have model character.

A3

In order to balance the contracts and make them symmetric in the sense of programming by a development contract, I associate three types to a programming language type. Two types (the implementation and the application type) reflect the views of the two contract partners and one type (the specification type) reflects the impartial contract view.

A4

The possibilities to communicate mathematical aspect of notations through computer user interfaces has not been exploited. I expect that tools as the one I am currently developing are suitable to educate high-school and lower-grade computer science and mathematics students. Mathematical education needs to be aimed at application in software engineering.

A5

Wirth and Gutknecht have carefully avoided ruining the achievements of procedure-oriented and structured programming. In the project Oberon, they added little to obtain an object-oriented language. Experience from this project has to reach a larger audience.