In Britain there is a very successful form of panel session, on a television program called “Question Time.” In this programme, four panelists, all public figures, are chosen to give a spectrum of viewpoints. There is always a figure from the two main political p<a.rties, usually one from the third largest party, and some complementary figure, perhaps a a business leader, union leader, or media person. This gives a wide spread of views. There are no position statements, the program is filled by discussing questions at about 10 minutes each. Each question is asked by an audience member, all four panelists respond, moderated by the panel moderator (a well known BBC ligure). The questioner then makes a brief reply, and there is a brief period of comments from the floor. The questions are submitted in advance by the audience members and the progr‘am organizers pick six questions that will be interesting. This panel on use cases follows roughly the same format. A well known (English!) 00 figure will question four expert panelists with differing views, to expose their views and their reasons for differing. There are no position statements, the 90-minute pane1 is filled by discussing eight questions. The questions are submitted in advance by the public and audience members. The moderator picks eight questions that will be interesting and help tease ap‘art subtle issues and differences between the panelists. For each question, all four panelists respond, moderated by the pane1 moderator. The questioner makes a brief reply, and there is a brief period of comments from the floor.

Anthropology is the study of civilization, particularly its societies, customs, structure, and evolution. Our premise is that there are cultureal "chasms" to be crossed to ensure the success of the technological beachhead established by innovators and early adopters of the OO paradigm. Our panelists will address the following questions:•What anthropological cultural factors have to be "matured" (and how?) to foster the success of the OO paradigm?•What mechanisms are required to facilitate communications between cultures of differing maturity?•What cultural chasms must be crossed to develop a successful organization/culture within the framework supported by the object-oriented paradigm (or more perrversely, is there anything "special" about the OO paradigm)?This panel will interest pracitioners as a forum to share and debate experiences related to our current-day software culture metamorphosis.

Abstract Temporal message‐flow diagrams (TMFDs), alternatively called sequence charts, interaction diagrams, event traces, or actor diagrams, are illustrations of a system's global message‐passing activity over time, and a pictorial aid to understanding the system's behavior. They are widely used for requirements and documentation for network protocols and object‐oriented applications. We present a general formalism for TMFDs, describe a suite of tools we have designed that employs this formalism, and present our experiences with these tools. The formalism and tools described serve to support and broaden the use of TMFDs in developing communicating systems.

Formalizes an interpretation of message-flow diagrams, allowing them to be translated into an executable forms, and develops a system, called "Cara", which allows a designer to enter message-flow diagrams and data operations, and to begin simulating with them immediately. Both control and data operations are translated into rules, which can be fine-tuned by the designer and used for simulation. In the Cara system, a flow-to-rule translator and a rule simulator operate concurrently with the designer. As the designer creates and modifies a diagram, the translator incrementally updates the architecture. The simulator uses the updated definition immediately to offer a next action to the designer (if one exists). In this way, the designer can always see whether the architecture is operating as intended.>

The internetworking capability of a network is typically provided transparently by protocols below the network application interface. However, network designs have been implemented in which the internetwork function is limited or absent. This paper describes one way to add transparent internetworking to such systems without affecting the existing network hardware and software. The solution consists of using application-level software and gateways that project a domain structure onto application names in such a way that neither the applications nor the underlying protocols need be aware of internetworking. A research prototype of this internetworking scheme has been implemented in the context of the NETBIOS application interface; the paper discusses its key features and the lessons learned.