Ewan Tempero Research Interests

Object-oriented programming languages

I first encountered object-oriented programming languages relatively early in their development and have always been interested in how they might help programmers. I have never agreed with most of the marketing claims made about them, but nevertheless believe they are a step in the right direction. My research in this area has primarily been to evaluate the claims and try an understand why they might have some basis. I was peripherally involved in the Emerald project at University of Washington, which involved the development of an object-oriented language, and I have also looked at concurrency models for object-oriented programming languages.

Software Reuse

One of the most common claims made about object-oriented programming languages is that it ``makes reuse easier'' and the argument presented to support this claim is that inheritance allows code to be reused. I have always found this argument to be fairly weak, and so began evaluating both the argument and the claim with my colleague Robert Biddle. We produced a model for understanding how programming languages support reuse of code, and used it to evaluate object-oriented languages. We established that it was the delegation aspects of inheritance, not the differential programming aspects, that provides the most benefits of reuse. We refer to these aspects as ``context reuse''.

From that early work we have explored Software Reuse as a means to improve programmers productivity. This has covered a number of areas, from improving requirements gathering and domain analysis, to examining various forms of tool support for reuse, from improving code repositories to making the simple cut-and-paste operation more directly useful.

Tool support for programmers

The most common tool used by programmers is the programming language. I have always been interested in programming languages and how they are used to solve problems. I've mentioned my work in object-oriented languages, but I've also looked at scripting languages (Perl and TCL) and functional languages (Haskell and ML). What I would like to see is some way to measure the effectiveness of programming languages. I have not made much progress on this, and the programming language research that I am familiar with has had essentially nothing to say on this either, but I live in hope.

I have also worked on tools to aid the programmer. My interest here has taken several forms, but all have been to support my primary research goal. As mentioned above, Robert Biddle and I have looked at tools for supporting various aspects of reuse. Related to this, I have built several tools for analysing code to try help the programmer understand code, either with the view to reusing it, or to evaluate how reusable it is.

Generally, I believe we should be able to do better than the current set of tools a programmer typically has available. This belief is based on the observation that even the current ``integrate development environments'' (IDE) provide little more than what was available 20 years ago: an editor, a compiler, and something to put it together (e.g., `make'). Editors are better, for example providing colour-coding to make it easier to read code (a significant advance in my opinion), and the integration of these tools allows certain operations to be done more efficiently (e.g., a 1-click compile and build). But these are just small variations on existing tools. There are no other commonly used tools. Further, the other main category of tools for programmers, CASE tools, have never lived up to their promise, and even today usually seem to require more effort than its worth to use.

Software Visualisation

Many of the tools I have been involved in building have involved some form of software visualisation. This is a consequence of the kind of support we have been trying to provide --- trying to understand code so that it can be reused or its reusability improved --- rather than a conscious choice of research direction. This has led to involvement with standard notations for representing artifacts in the software development process.

The software development process

I am interested in all parts of the software development process. Design, particularly object-oriented design, has been a particular focus of a number of tools I have built. Recently I have been interested in the transition between requirements gathering and design.

The technique currently in vogue for requirements gathering is ``use cases''. My interest is in how to go from a use case model to an object-oriented design. Current wisdom provides little advice on this step. References are made to ``domain models'', ``object-oriented analysis'', and similar things, but observing people using such techniques or just trying to make the leap to the beginnings of an object-oriented design I am convinced that more specific techniques can be developed. The approach I am investigating (with Robert Biddle and James Noble) is to regularise the definition of ``use case'', and then use this to drive the object-oriented design process.

I do have other research interests that I pursue on occasion.

Computer Science Education

Perhaps the most unexpected aspect of my research has been my work in computer science education. While it has been unexpected, in hindsight it is not surprising. In order to help programmers be more productive I've had to understand as best I can the issues the programmers face, including problems that arise in using programming languages and designing software. Since these issues are also faced by those learning to program, the understanding I have developed has been of direct benefit to my students.

Theory of Distributed Computing

My PhD research was in this area and I can occasionally be tempted to look at interesting problems.

Women in Computing

I have participated in a project whose goal is to increase the retention rate of women in first year computer science courses.