Abstract. Though programming languages and programming styles evolve with remarkable speed today, there is no such evolution in the field of program documentation. And although there exist some popular approaches like Knuth’s literate programming system WEB [26], and nowadays JavaDoc [15] or Doxygen [16], tools for managing software development and documentation are not as widespread as desirable. This paper analyses a wide range of literate programming tools available during the past two decades and introduces ProgDOC, a new software documentation system. It is simple, language independent, and it keeps documentation and the documented software consistent. It uses L ATEX for typesetting purposes, supports syntax highlighting for various languages, and produces output in Postscript, PDF or HTML format. 1

Existing CASE tool diagram editors have large, complex, and sophisticated graphical user interfaces. Because of their size, these interfaces are difficult to learn and hard to use. A minimal interface for a diagram editor provides only the essential behaviour required by the user in the simplest possible manner. Minimal interfaces are smaller than traditionalinterfaces, and should be easier and quicker to use. 1. Introduction A COMPUTER AIDED SOFTWARE ENGINEERING tool (or CASE tool) is a drawing tool used to produce and manage diagrams representing a software system's design. A CASE tool typically embodies the definitions of one or more software development methodologies. The tool allows a designer to enter diagrams in the method's notation, checks the diagrams for consistency, and may generate code or produce diagrams from pre-existing code. Unfortunately, providing information to a CASE tool often serves to subvert the design process. For example, Jim Coplien [3] recommends that key...

Open Database Connectivity (ODBC) is a call level interface to databases. In contrast to Embedded SQL and PL/SQL, programs using ODBC are meant to be database independent. This is achieved by an additional layer between the application and the database. In this paper we regard interoperability not as the question if it is at all possible to work with different DBMS's 1 but how easy and convenient it is. We will show that there are some deficiencies in the design of ODBC which reduce the degree of interoperability but also that these can be remedied with moderate effort. 1 Accessing Databases Many applications need to access large amounts of data. Therefore many of them use databases. For a query language SQL is a widely accepted and used standard. But depending on the degree of integration of SQL into the application there are at least three different ways to bind SQL statements to the application code [Ven95]: ffl Embedded SQL, embedding SQL statements directly into the application...

Persistence is the property of objects to outlive the programs that create them. It is the most important feature of object-oriented database systems. Persistent objects can exist for a long time, but in this time the environment may change. Therefore adapting objects is often necessary. In most cases it is enough to change the values of some attributes, but sometimes also the types of the objects have to be modified, for example, when attributes have to be renamed or changed. The modification of types in a database is called schema evolution. In this report we show how schema evolution was added to Oberon-D. Oberon-D is an ongoing research project which adds database functionality to the Oberon system [ReWi92]. In Oberon-D persistence is obtained by a persistent heap on the disk [Kna97]. Persistent objects, which are not referenced by other persistent objects are reclaimed by a Stop & Copy garbage collector. Schema evolution is done during a garbage collector run. Objects are not phys...

: Our vision is an environment that allows (ordinary) PC-clients to profit from a rich collection of multimedia programs such as selected TV channels, video on demand, teleported lectures etc. In this article, we present the design and implementation of a corresponding local infrastructure both from a hard- and software perspective. Innovation highlights are (a) a switch-based network with guaranteed transmission bandwidth for audio/video streams, built-in multicast support and globally accessible display frame buffers, (b) a system for the integrated display of remotely generated video streams at the client site and (c) a central server for the management of the available multimedia programs. Keywords: client/server multimedia system, quality of service, networked peripherals, Oberon. 1. Introduction Thanks to the power, versatility and low cost of today's personal computers multimedia has become an attractive and widespread field of application. The unique combination of high-quali...

Optimizing compilers tend to be much larger and much slower than their straightforward counterparts. Their designers usually do not follow Oberon's maxim of making things "as simple as possible", but are inclined to completely disregard cost (in terms of compiler size, compilation speed, and maintainability) in favor of code_quality benefits that often turn out to be relatively marginal. Trying to make an optimizing compiler as simple as possible and yet as powerful as necessary requires, before all else, a measurement standard, by which both simplicity and power can be judged. For a compiler that is written in the language it compiles, two such standards are easily found by considering first the time required for self_compilation, and then the size of the resulting object program. With the help of these benchmarks, one may pit simplicity against power, requiring that every new capability added to the compiler "pays its own way" by creating more benefit than cost on account of at leas...

Oberon-2 is a refined version of Oberon developed at ETH. It introduces type-bound procedures, read-only export of data, and open array variables. The For statement is reintroduced. This paper concentrates on type-bound procedures which make Oberon-2 an object-oriented language with dynamically-bound messages and strong type checking at compile time. Messages can also be sent as data packets (extensible records) that are passed to a handler procedure and are interpreted at run time. This is as flexible as the Smalltalk message dispatching mechanism. Objects carry type information at run time which allows dynamic binding of messages, run time type tests, and the implementation of persistent objects. Oberon-2 is available on various machines. OVERVIEW In 1987, Wirth defined the language Oberon [1]. Compared with its predecessor Modula-2, Oberon is smaller and cleaner, and it supports type extension which is a prerequisite for object-oriented programming. Type extension allows the progra...

The notion of component-oriented programming is largely based on a model of software distribution: if a certain software artifact can be distributed independently of other similar artifacts, and yet be smoothly integrated into an environment composed of such artifacts, then we call it a component. Unlike established areas of computer science, such as object-oriented programming, component-oriented programming has no coherent programming model associated with it at this time, nor is there a general agreement as to what the run-time structure of component-based systems should be. Basing a whole new technology on the "middle" ground of software distribution is at once strange and risky. A host of potential misunderstandings and incompatibilities will arise unless the existing model is soon extended twofold: On one hand, the mechanics of component interaction need to be brought semantically closer to programming languages. On the other hand, components need to be mapped onto ...

this paper, we present the design of an operating-system emulator. This software interface provides the services of one operating system (Oberon) on a machine running a different operating system (Macintosh), by mapping the functions of the first onto equivalent calls to the second. The construction of this emulator proceeded in four distinct phases, documented here through examples from each of these phases. We believe that our four-phase approach can be beneficial whenever a larger software system needs to be adapted from one architecture onto another. In conclusion, we relate some of the lessons learned and propose guidelines for similar engineering projects