Table Tool System

David Lorge Parnas keynote from Oopsla 2007 is available as a podcast.

Computer Scientists have been talking about the use of of object-orientation (under a variety of rubrics) to achieve "separation of concerns" for more than 40 years. In all that time, it has been taken for granted that it was the structure of the program text itself that mattered. Whenever it was felt that additional information was needed it was assumed that this would be closely associated with the program text either as simple comments, as in-line assertions, or "woven" in with the program text using elaborate tools.

This talk takes a different position. It argues that for true separation of concerns we need an integrated set of separate documents, some of which are to be read by people who will never read the code, some that describe the structure of the code, and some that describe the behaviour of individual components. It describes a collection of mathematical ideas and notations that make it possible to produce documentation that is both precise and readable. We then describe the use of these documents in testing and inspection. Finally, it discusses the way that other programming paradigms, particularly functional programming, can be used to make these documents more useful.

In it he discusses the Table Tool System (TTS), a system for writing precise software documentation. He quotes some impressive quality results from using this system when developing real world software.

I ask the LtU community to comment on this as he mentions the fact that the tabular notation his group has developed is precise enough to allow the execution of it for e.g. testing purposes, although very inefficiently. It might therefore be interesting to ask if the TTS in fact constitutes a new programming language in itself (it seems to me it does) and whether it's just waiting for an optimizing compiler writer to come along. From the podcast I gather that the notation is in fact written in a pure declarative/functional style and it might be interesting to explore whether the tabular notation could be useful for writing code for an existing functional language and reap some of the benefits he claims, such as the "code" being accessible to non-programmers.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I missed most of this talk,

I missed most of this talk, so I won't comment on it generally, but I do tend to agree with you that a shorter way of saying "sufficiently precise requirements language" is "programming language." In fact, several people noted the connection between what Parnas describes and what Edwards subsequently showed, but no one was ready to comment in any detail.