Note: Papers are distributed here for the convenience of students in CIS 610. Many of the papers here are copyright by their authors and/or the publishers. I believe reproduction for a small number of students is permitted by IEEE and ACM copyrights, and/or fair use provisions of copyright law. I have not password-protected this page, because it may be of interest to others outside the class, but in respect of the copyright holders I ask that the papers be downloaded and printed only by students in the seminar.
Literate Programming on a Team Project, Norman Ramsey and Carla Marceau [PDF]
You may also be interested in ...
The best-known "design recovery" tool is Rigi, from Hausi Müller's research group at the University of Victoria. I am not sure which paper we really should start with, but "Structural Redocumentation: A Case Study", Kenny Wong, Scott R. Tilley, Hausi A. Müller, Margaret-Anne D. Storey, IEEE Software, Vol. 11, No. 6, pp. 501-520, January 1995, looks relevant. It is available as a PDF file.
A "reflexion model" is something like a structural diff between a graph representation of a design model (how we think the design is organized) and a model derived from the source code of a system. There is a pretty good overview of the technique on a web page maintained by Gail Murphy.
Readings:
A "Grid" model imposes two different hierarchies over the same software system. It is relevant for a couple of reasons. First, like a reflexion model, it provides a way to compare the "as-built" structure of a software system with a high-level design of its intended structure. Second, imposing two different hieararchies may hint at ways in which multiple structural views (different ways of looking at the architecture) might be imposed over the same software system.
Readings: TBD
A software bookshelf is a hierarchically organized hypertext presentation of a software system. It can be partly dynamic, and can be incrementally reconstructed as a system changes. This project apparently began when the principal investigator, Ric Holt, was at U. Toronto, and is somewhat divided between two sites now that he is at U. Waterloo.
Readings (all from web pages at U. Toronto or U. Waterloo):
Steve Reiss at Brown University has been pushing the envelope for graphical programming tools for more than a decade, starting with the Pecan and the Brown Workstation Environment (BWE) and continuing with Field and, most recently, Desert. There are a few clear themes running through all of this work:
Readings:
There does not yet seem to be any paper that really describes the Desert environment from the perspective of a user. I may pick out a paper on Field, rather than Desert, to get that perspective.
Also listed below under program visualization is a Brown U. tech report on 3d program visualization.
There is a good deal of overlap between program visualization and graphical programming environments, but they are not quite the same thing. Program visualization tools could be part of a graphical programming environment, but they could also be part of a reverse engineering toolkit such as Rigi.
Readings:
We should probably also read something on CIA or CIA++. The second paper above may help us choose some additional readings.
A software presentation system should describe the why as well as the what of a software system. This is particularly important for evolution, since it is difficult to tell whether a peculiarity of a system in its current state is essentially accidental or is a carefully considered design decision which is essential to maintaining some property of the software. But how do we capture the rationale behind decisions, and present it in the system?
An Issue-Based Information System (IBIS) is a way to support and record the deliberations leading to a decision. We read:
The gIBIS paper is a classic, and certainly among the more substantial papers we have read this term. Alas, the "Design Journal" project, of which it was part, seems never to have come further than this initial step.
One of the issues raised by the gIBIS paper is the distinction between the history of a decision, which is really what gIBIS captures, and a clear presentation of the decision once made. Should the content of the IBIS tree be reorganized into a more coherent structure? The distinction between "How it got this way" and "how to understand it" is also the subject of:
This paper has not aged as well as the gIBIS paper. Some of its assertions, which once seemed at least mildly controversial, are now old hat. This makes problems of some of the remaining assertions more apparent. For example, there seems to be an inconsistency between insisting, on the one hand, that a requirements document should be free of implementation decisions, and on the other hand including a specification of the machines on which software may run in the content of the requirements document. This problem (and some others) seems to be the result of not distinguishing between a problem-oriented requirements document and a specification of one particular solution which has been selected for implementation. The former should be free of implementation bias, the latter cannot be.
Nonetheless there are some intriguing relations between the Rational Design Process paper and the gIBIS paper. The "ideal documentation" advocated by Parnas and Clements is structured around a set of "concerns", which could quite reasonably be taken as an initial set of issues in an IBIS structure. Parnas and Clements also point out that module interface specifications "are actually produced by a process of negotiation between implementors, those who will be required to use it, and others interested in the design, e.g., reviewers." Could such negotiations be supported by an IBIS? Would that be an effective way to develop interface specifications, and to effectively link interface specifications to their rationale? Or would capturing rationale in this way inevitably lead to what Parnas and Clements dismiss as "stream of conciousness" documentation?
gIBIS can be considered a kind of "groupware" support. A more recent project for supporting communication and group decision making in software development is Conversation Builder.
This is arguably "out of scope" for our seminar, but since software presentation has a lot to do with making software architectures more apparent, and thereby helping to preserve them, it is perhaps worth our while to think a bit about the information content of software architectures.
For a start, we'll read:
Despite appearing in a non-refereed publication, this is one of the papers that kick-started the field of software architectures, and it is widely cited. A somewhat different view of the field can be taken from some of David Garlan's early papers on the topic, and later from the work of David Garlan and Mary Shaw at CMU. A collection of papers presenting the Garlan/Shaw view of the field has been published as a book. [tbd: Add ref here]
A distinction is often made between the architecture of a particular software system and an "architectural style" of a family of systems. Styles may be quite specific to a particular domain (e.g., embedded control systems), or as general as blackboard systems or the familiar Unix "pipes and filters." So far, there is no clear definition of architectural style that is accepted by everyone, but there is a growing collection of examples that most researchers are willing to accept.
Let's also read:
Fair warning: I may not be entirely impartial regarding the C2 work, since I have past and ongoing collaborations with some of these researchers.
The C2 work is interesting in several regards. C2 constrains the ways software modules can be connected. The communication topology has a graphical representation, and that representation differs from typical "layers" or "uses" hierarchies as well as typical "block diagrams." Because the topology is constrained, its representation is simpler. This should typically be the case of architectural styles whatever is the same for all instances of a style need not be represented explicitly in an individual instance.
Now that we have read and discussed this paper, there are a couple of other points to add. As Craig pointed out, there is a pretty clear link between architectural styles and software presentation --- a system that follows an explicitly represented architectural "style" should be much easier to understand, not only because there are conventions for presenting the software structure diagrammatically, but also because the dependencies of a component are constrained by the style.
Recently the C2 researchers have looked at how their architectures could be represented in UML, using the UML constraint notation to represent constraints of the C2 "style." As one would expect, the resultng UML diagrams are somewhat more complex than the corresponding C2 diagrams, despite efforts to "factor out" C2 constraints and represent them once per system, rather than repeating them for each component. Again this is somewhat afield of our topic, but it is interesting nonetheless to consider the costs and benefits of mapping a domain-specific architecture representation (the common term is "architecture description language") to a more general design representation.
More pertinent to our topic, how should software presentation systems support domain-specific and even system-specific design notations? To what extent can they exploit the constraints of an architectural style, and/or preserve those constraints? I think these questions push us toward the interface between software presentation and software analysis & test.
Last update: 24 November 1997