University of Oregon Computer & Information Science

Announcements (updated Tue, Mar 28, 2000 10:34)

Topic

You won't find the term "software presentation" in software engineering textbooks, or as a standard term in the software engineering research literature. There is a body of literature (and systems) related to software presentation, but it is scattered among several different sub-fields of software engineering, including so-called "literate programming," graphical software development environments and program visualization tools for reverse engineering, hypertext tools for software documentation, even support for requirements negotiation.

A "presentation" is a document or activity designed to help people understand something. We will look at papers and systems from several sub-fields of software engineering and related fields, looking for basic problems and approaches in making complex software systems understandable. I am particularly interested in the problem of maintaining relations between complementary descriptions of different aspects of software, or at different levels of abstraction. In a linear, phased software development methodology, this might be called "traceability" among documents produced in different phases of development. In an incremental development, in which requirements, design, and implementation may all be changing together, maintaining relations among them is all the more challenging. If we consider those relations as consistency constraints, then it may also be natural to tie program presentation with program analysis and testing.

Format

In Fall 1997 I led a seminar course on software presentation in which we mainly read and discussed papers. We will read a few papers again this time, but I want to take a much more hands-on approach, in which the center of our discussions is a project with a concrete goal.

The Project

We will attempt to construct a "presentation" of the Apache web server. The Apache web server is a modest size system, large enough (and widely used enough) to not be considered a "toy" example, but small enough that we have a fighting chance to make sense of it in a single academic term. It has several other advantages as a case study: It is relatively cleanly organized, there is some written rationale of the design to bootstrap from, and all of the source code is freely available.

Initially I want to attempt to bring two sets of tools to bear on this: The reflexion models tool kit from Gale Murphy's group at U. British Columbia, and the program database toolkit (PDT) from the computational science research group in our own department. The PDT toolkit will be used to produce what is called a "source model", which we may augment with other sources of information. The reflexion models toolkit will be used to build and maintain a relation between the "source model" and a "design model" (which we'll need to build).

The first steps will be to read a paper on reflexion models, obtain and install the tool, and begin exploring the available documentation of the Apache system to formulate one or more models of its design.