A collaborative environment for role-playing in object ... - Springer Link

© Springer-Verlag London LEd Virtual Reality (t 998) 3:49-58

A Collaborative Environment Role-

Playing in Object Space C. Hand, S. Lingard, M. Skipper Deportment of Computer Science, De Montfort University Leicester, UK

Abstract: We present some experiencesfrom the development and early use of CRCMQO, a CollaborativeVirtual Environment (CVE) which supports the CRC cards software design technique, implemented initially using a MQQ. After briefly describing CRC. we discuss how CRCMQQ differs from other collaborative environments for software engineering. The role-playing metaphor is discussed, followed by the results of an analysis of the CRC task and a description of how the results were incorporated into a second prototype system, this time using a graphical user interface. Keywords: CRC cards; MQQ; Role-playing; Spatial understanding; Views

Introduction This paper describes our experiences with the design and implementation of CRCMQQ, a CVE which supports the CRC Cards design evaluation technique. [ h e original prototype was entirely textbased, having been created using a MOO (MUD, Object Oriented) as the development environment. Several problems were encountered in using a textbased system for this kind of task, and so a further investigation was initiated to explore possibilities for a graphical user interface. This paper describes the CRC technique very briefly and then summarises the background to our work. We then relate some early experiences with CRCMOQ and go on to describe the analysis, design/implementation and evaluation of a second-generation CRCMQ© with a graphical user interface,

Collaborative Software Design using CRC CRC Cards were first introduced by Beck and Cunningham [1]. They have since been adopted by a number of authors as a valuable part of the ObjectOriented (OO) analysis and design process (e.g. [2]. Beck and Cunningham argue that QQ designers should adopt an 'anthropomorphic perspective' and that "the most effective way of teaching [...] objects is to immerse the learner in the 'objectmess' of the material" [1]. The result of this perspective on obiect design is the CRC card, typically a physical 6" x 4" index card divided into three areas which identify the role of an obiect in a design: class name, responsibilities and collaborators (hence "CRC"). The CRC design session consists of participants role-playing the classes represented by

the cards they hold. Sending messages to each other, and creating and destroying classes (cards) provides insight into the relationships between the objects being designed. The primary aim of the CRCMOO project is to create a Collaborative Virtual Environment (CVE) which may be used to perform and record CRC sessions, while providing enough structure that the protocols and turn-taking of the the technique are enforced (to help novices in particular).

Background: RolePlaying in Object-Space Microworlds An important motivation of Papert's 'microworlds' [3] shared by many subsequent projects (including CRCMOO) was to make abstract concepts into concrete objects which can be manipulated and more easily understood. This was also an underlying premise of Randy Smith's Alternate Reality Kit or ARK [4] an object-oriented simulation toolkit implemented in Smalltalk-80, and later work on the SELF language [5]. Both provided programmers with a graphical interface to a virtual world inhabited by objects, and allowed them to interact with these objects directly without the need for explicit tools such as browsers or debuggers. Both ARK and SELF use prototypical inheritance, that is to say that existing objects are copied and modified rather than defining classes and subclasses which are instantiated as objects. As Smith points out, when designing ARK he rejected Smalltalk's class/obiect-based inheritance since "replacing classes with prototypes is another move away from the abstract and towards the concrete ° [4]. Whilst the SELF interface creates a virtual world, it does not immerse programmers in that world. They are able to manipulate and browse the obiects but are not encouraged to take on their roles. In creating CRCMOQ we wanted to exploit the immersive nature of MUDs and place programmer-designers inside the same virtual world as their objects.

we may adopt the theatre as a metaphor and allow Designers to Role-Play their designs in a Scenario. Yet another Smalltalk-based system from Xerox PARC, "Programming by Rehearsal" [6] used a metaphor of rehearsing performers for a stage production to allow non-programmers to create educational software visually Their principle that "only things that can be seen can be manipulated" again echoes the theme of transforming the abstract into the concrete. The idea of using the Theatre as a metaphor for understanding computers has subsequently received further attention and development, most notably by Brenda Laurel [7]. Dramatic theory is starting to be incorporated into the design of virtual realities [8], and as a well-developed theory of human-human interaction it may welt have an impact on the design of groupware systems too~

Collaborative Environments and Software Engineering Much of the work in applying CSCW to Software Engineering has concentrated on issues such as collaborative reviewing of program code [9,10], or software deveIopment environments [11]. Real Time Issue-Based systems (e.g.[12]) may also be used in debating the early stages of software designs. In contrast, CRCMQQ participants are roleplaying the software objects of interest, rather than simply discussing them (Beck and Cunningham's "anthropomorphic perspective"). Remote or colocated participants have an embodiment and they use the MOO as a persistent virtual place for synchronous interaction, both human-tohuman and human-to-obiect. In this sense, MUDs and MQQs form a useful basis for implementing CVEs. The anthropomorphic perspective in CRCMQQ enables users to become engaged with the objects (the ultimate focus of the CRC task) by playing their roles. However, rather than constraining users to work at this level continually, they are also free to move to conceptually higher levels for example, discussing the collaborators of a class or negotiating responsibilities. This freedom is partly due to the textual, discussion-based nature of the system: both commands and utterances are entered via the same textual interface, but while the commands must be -

Role-Playing Metaphor The concept of rote-playing obviously comes from the theatre: whereas Actors play Roles in a Scene,

D

C~ Hand, S. Lingard, M Skipper

syntactically correct, the content of utterances is completely unconstrained. In practice, these conceptual levels turned out to be more numerous than anticipated, This and other observations, such as the need for the flow of control to be embodied in a 'concrete' object, are described below.

one of the cards they are holding. This level is the virtual analogue of a real-world CRC session.

Proposed Software System: The cards which exist in the 'CRC Session' level represent the classes in the software system being designed. The roles being played correspond to run-time instantiations of these classes.

Experiences with CRCMO0 Problem World: The problem domain contains

Conceptual Levels

the 'real objects' which the software system is modelling.

During informal evaluation sessions we found that switching between a nurnber of conceptual levels was necessary (see Fig. 1).

In addition to these levels experienced by users, we ourselves experienced an extra level (as designers and implementors of the system), in which we reflected upon and discussed the performance of the CRCMQQ system as part of the debugging process, (This turned out to be rather confusing!) An attempt has been made to directly support switching between these levels in the new graphical user interface - see page 53.

Real World: At this level we have the physical embodiment of users interacting with their computer terminals. Human-to-human interaction is possible at this level if users are in the same room, although we typically discourage this since discourse going via this channel is not logged in any way, and serves to confuse non-local users, (On the other hand, this may find uses in 'Wizard of Qz' type experiments.) Users' physical embodiments have a v i r t u a / embodiment in CRCMOQ at the next level down,

Cognitive Aspects the Task Another aspect of the task highlighted by informal evaluation of CRCMQQ is that it is necessary to repeatedly monitor the status of messages being sent/received/rejected, turn-taking and so on. Due to the nature of MQQs, 'looking' at the object requires issuing a command. Users also find themselves trying to hold state information in short-term memory Some users of CRC in the real world have adopted ways of dealing with these problems. For example, in the Object Game [13] a sponge ball is used as a 'token' to represent the flow of control.

CRCMO0: At the CRCMOO level everything is a MOO object, including the embodiment of users (known as 'players' in MOO terminology) and the CRC cards they are 'holding'. CRC Session: At

any given time a player may be role-playing a class, which itself is represented by Real World

CRCMOO

CRC Session

Software System

Tho,0s :: °Per° e" I

i

~dation

Problem World

i

plays " a

"~ I Software Object }

I

Object ]

Fig. 1. Conceptual Levels in CRCMQQ.

A Collaborative Environment for Role-Playing in Object Space

In a similar way we adapted our initial implementation to include an explicit 'token', which at any one time would be held by the person about to send the next message. Real-world users also sometimes find that large Post-It notes make good CRC cards, since they can be placed on a whiteboard in locations close to (or even overlapping) their collaborators, or with lines drawn between them to show inheritance. This use of spatial organisation, along with the short-term memory problem mentioned above, has led us to investigate further the CRC task with a view to adding an explicit spatial model to CRCMOO, along with a graphical user interface.

Further Analysis CRC Task Once the decision to build a prototype graphical interface had been taken we briefly conducted a further analysis of CRC-style tasks in an attempt to better understand the role of human spatial understanding. According to Brooks [14], the modality in which information is presented can affect the memory for it. He looked at the textual and auditory presentation of spatial statements, and discovered that spatial statements were remembered better when presented auditorily, and non-spatial statements were remembered better when presented textually, rather than auditorily. In investigating multi-tasking and visuo-spatiaI working memory he also found [1 5] that visualising letters used cognitive resources that were also needed for reading and motor activities but not for verbalising, indicating that for tasks involving visualisation a verbal response was easier than pointing to the answer or writing it. For our own analysis, a questionnaire-style test covering modality/recall interaction was administered Lo eight subjects. This featured a set of memory tests which involved the memory of concrete spatial locations, concrete objects, abstract spatial locations and abstract objects. Four sets of four statements containing a combination of these stimuli types were presented. For each set the person had to either read and write the statements from memory, or listen to and write down the statements from memory, or read and dictate the statements from memory, or listen to and dictate the statement from memory.

D

C. Hand, S. Lingard, M. Skipper

The results for this section of our tests indicated that these different modalities had differing levels of difficulty. The least number of errors was found, as might be expected, in the read/write condition, which could be easier, as it is perhaps the most common method used for remembering information. The second fewest errors were found in the spoken/spoken condition. This indicated that the difficulty might not be the modality the information was presented in, but the switch between modalities. This dealt a blow for the idea of having verbaI communication between remote players on the CRCMQQ, unless verbal input and output could be made to be the main method of interaction with the program. However, it did indicate that consistency in the modality information is presented in an interface would help reduce unnecessary cognitive load, and aid memory. The results for this section also indicated that the hardest stimulus type to remember was the abstract spatial location, especially in the written/ spoken and spoken/written conditions. The easiest were the abstract object, and concrete spatial stimuli, especially in the written/written and spoken/ spoken conditions. It is suggested that this is because these are relatively easy to visualise. The implications for this as far as the prototype is concerned are that abstract spatial locations, or the spatial organisation of abstract information such as card layout should be welI supported, preferably diagrammatically in the interface, to reduce memory Ioad and error. In addition, the concept of "whose turn it is" can be thought of as an abstract spatial concept (the most error prone stimulus type in the memory tests) in the sense that the 'turn' is situated somewhere, or with someone in the session. Remembering "whose turn it is" is one of the main problems of the CRC card technique in real tile sessions. These findings suggest that the cognitive effort required to remember turns would be greatly reduced by representing the 'turn' in the form of an abstract object, such as a token, since this was the least error prone stimulus type in the memory tests. This could then be presented visually, and moved around from card to card as the turn was passed. This would present a permanent visual reminder of whose turn it was, and given supplementary information attached to the token, could list the current message and its sender. The overall implications for this part of the research are that given the need for spatial organisation of card layouts etc. in the CRC card session, the interface should provide information in a diagrammatic form where possible, and pro-

vide a clear view of all information that might be represented spatially, such as the locations of the other players and object hierarchies. The second part of the questionnaire concentrated on specific problems of the CRC card technique. The results for this section indicated that most people tended to think visually, but preferred to express the sequence of events in a CRC card session using structured text. This was certainly true for the first scenario which was easily visualisable. However, for a more abstract set of cards, half of the participants used a combination of text and diagram, where the diagram was mainly a visual aid. They still remembered whose turn it was by backtracking through the textual sequence they had written. The implications for this are that although visual or diagrammatic representations of the characters/classes seem to be more intuitive and the preferred mode of thinking about a scenario, a textual representation of the sequence of events is preferred for clarity and reference, and possibly because it gives a clear representation of the order of events. This suggests that the interface needs both a diagram of what goes on in a session, as well as a structured text representation of it for those who need to back-track, or refer to previous actions. As mentioned above, a problem with the textbased system was the increased cognitive load due to switching between conceptual levels of the system while working with it. There is a clear parallel between this idea and the problem of modality shifting identified in the results of the questionnaire, namely that the problem is in the shift, rather than the world itself. This suggests that some provision should be made in the interface for a visual representation of these worlds where appropriate, to reduce the amount of shifting necessary, and free the player's cognitive resources for dealing with the problem at hand.

Design a Graphical Inter ace Despite being strong believers in the power of MObs to support rapid prototyping of collaborative systems, we had no doubt that in CRC we had encountered a task for which text was inherently unsuitable - the tack of graphical and spatiaI representation was increasing the user's cognitive toad unnecessarily. The requirement to issue commands

to access status information was also an impediment. Taking into account the findings mentioned above, it was decided to develop a new user interface, with three main objectives: 1.

Provide the ability to represent information spatially.

2.

Explicitly support working at the different conceptual levels in the system.

3.

Maintain the ability to 'chat' easily with other users (initially using text, with the possibility of adding digital audio later).

A prototype system was constructed using Visual Basic running under MS Windows on a PC. Rather than being fully functional at this exploratory stage, certain aspects were hard-coded for the sake of rapid development. Testing was undertaken using a simplified version of the simple but well-used Library scenario described by Wilkinson [1 6].

Adding the Spatial Components From our own experiences and those reported by Wilkinson [1 6], real-life CRC sessions use space in three ways. FirstIy, it is common to arrange the cards such that their position (e.g. on a table top) is close to other cards with which they collaborate, revealing 'clusters' of responsibility/collaboration and even holes to which users point when explaining as-yet undefined roles. Secondly, the location of cards held by participants around a table may provide coursegrained information as to their roles. Thirdly, the object hierarchy may be drawn in a tree to show inheritance relationships within the system. These spatial techniques were implemented in the prototype as different 'views', each available in a separate window on the screen. The Object tnteractioh View (Fig. 2) is analogous to looking at a table-top with cards spread out according to their roles. Unlike a real table-top, it is possible to double-click on any card to re-arrange the whole set, with proximity determined by coi-laboration. In addition, the Object Interaction View provides useful state information by displaying the current location of the Token, and the path it has taken in moving between cards. The Table View (Fig. 3) shows the participants in a session and the cards they hold. State information is again provided by displaying the Token in its current position (i.e. sitting on one of the cards), which in this view also indicates which

A CollaborativeEnvironment for Role-Playingin Object Space

Fig. 4. Card vievv.

Using Views to Support Level-Switching An additional view, a Card View (Fig, 4), was also implemented to facilitate more detailed interaction with cards such as message sending, Although Fig. 4 only shows one card, it is possible to view many cards simultaneously, or to minimise cards into icons when they are not required to be displayed fully. Responsibilities and collaborators are listed as with traditional cards, but at any time a responsibility (which corresponds to a message send) may be selected and, by pressing the 'go' button, may be used to initiate the sending of a message (as long as the card in question currently holds the token). Figure 5 shows how the four independent views map onto the most important conceptual levels in the CRCMQQ system.

user should take the next turn. Apart from providing an over-view of the session, this view is intended to ground the users in the virtual environment, helping to create a feeling of being co-present with the other participants. Since all participants have a representation in this view, it is possible to make use of direct manipulation tech~ niques to interact with them - accessing a user's status information, or sending a private message (a 'whisper') for example. The OOject Hierarchy View displays the cards currently defined in the session according to their inheritance hierarchy, in other words it displays an inheritance graph for the current set of classes, This is calculated automatically (and suggests possibilities for interfacing the system with CASE tools, which has always been a tong-term aim of the CRCMOO project),

D

C. Hand, S. Lingard, M 5kipper

Chat Support One of the main benefits of using a MOO-based system is that since all interaction takes place via the keyboard it is always as easy to 'talk' to other participants as it is to issue commands to the rest of the system. Since only one modafity is used, there is no need to switch between communication channels either physically or mentally: hands may stay on the keyboard and the user is oriented towards text-based interaction continuously In moving towards a graphical user interface this benefit has been lost. Since one of our obiectives was to maintain some easily accessible form of chatting, we decided to keep text-based chatting in the system even though this sits uneasily with the work mentioned previously, which suggests that switching between modalities should be

1 1 Object Hierarchy view

Card view

V-

Table view

I

Real World

f

I

CRCMOO

I I t

I I I

I

, (mooobiec l I I

,I

I

holds

I I I

t

CRC Card holds

i m o o obiect

..........

I I I I I I

Class

Problem World ]

/ Class

I t

1

instantiation

pl~ys Software Object

Designer

t

... Object Interactions view

Software System

I

i

operates

I

CRC Session

.. J

I

I

Obiect

]

I

Fig. 5. Views versusconceptual levels.

avoided. To minimise the effort involved in issuing textuat utterances, a chat window is present on every card (Fig. 4).

were. All four subjects were able to complete the trial without any errors.

Results Other Features Two features not discussed here in any further detail are the usage graph, which shovvs the number of collaborators for each card (and so helps identify redundant classes), and the system log, which uses structured text to represent all the message send/ accept/reiect events plus comments.

Evaluation

Prototype

The prototype was evaluated briefly using four academic staff who have an interest in using CRC for teaching purposes. The main obiectives of the evaluation were to ascertain whether the different views lessen the problems of spatial memory overIoad and shifting modalities, whether the token was useful in addition to the interaction tog and whether the different overviews lessen the levePswitching problem outlined above. All subjects carried out a mini CRC card scenario which was interspersed with questions designed to elicit information about the spatial arrangement of the people, the token and the cards in the session. The scenario was aIso interspersed with questions about the different views of the data and what the initial reactions and thoughts about these features

The results of the questions have been categorised according to Spatial Memory Load, The lbken, Modality Shifting and Level Shifting.

Spatial Memory Load All participants agreed that the Table View gave them a feel of being in a CRC community, more so than a list of participants would do, and generaZly helped them to associate the other players with the roles in the game, and understand the objects better: At least three of the participants felt that this view reduced the need to visualise the players, as the view was a sufficient reminder. This suggests a reduced spatial memory load, because of the reduced need for visuafisation of the players and their cards. All participants said that they would refer to the automatic object hierarchy either during or after a session, However, one participant suggested that it would be useful if the objects gave access to information on their dass/subclass etc. for teaching purposes. Another participant suggested that an object model would be more useful. Three participants said that they would be more likely to use this than they would to draw up an obiect hierarchy

A CollaborativeEnvironment for RoIe-Playingin Qbiecl:Space

during a session. This again suggests a reduced spatial memory load, and reduced cognitive processing generally, because the task of drawing this up by hand would no longer be necessary and there would be no need to visualise the information as a substitute. When asked which views were necessary to provide the essential information about a session, all participants stated the table view and the interaction log. One stated the object hierarchy, one the card view, one the usage graph, and one the obiect interactions overview. The reasons given were that these views provided the essential information required to understand the session. This suggests that the views provide adequate information to understand a CRC card session, and therefore reduce the cognitive load which would be required to remember this information, if coming into a session part of the way through. On the Object Interaction view, all players successfully identified the meaning of the directional arrows of the auto-group facility. All participants thought that this view of the object interactions was beneficial, and one stated that it was an improvement on the previous view, which represented active messages with arrows during a session. This again suggests a reduced spatial memory load, as the grouping of cards spatially according to their interactions is an important part of the CRC card session, and one that was almost impossible using the text-based CRCMOO. All the participants stated that they felt the interface provided enough features for them to concentrate on the problem in hand, rather than having to try to remember their position in the session or the next action to be taken. Three participants stated that they felt that they did not have to remember any information about the session at any time. One qualified this by stating that he could get the information visually as needed, and another qualified this by saying that he just needed a little time to become familiar with the icons. This is a clear indication that the system of views reduces spatial memory load and memory load generally to the minimum needed to use the icons and system generally. When asked the extent to which the interface reduced the amount of information which the participants would have had to carry around mentally in a conventional CRC card session, two participants stated that it provided great reductions in memory load. In addition, one participant replied that the availability of the different views provided him with a great and very welcome sense of control.

C. Hand, S. Lingard, M. Skipper

This again indicates a great reduction in spatial memory load provided by the view system, and a reduction in memory load generally, sufficient in parts to provide a feeling of understanding the session as a whole, rather than a collection of different parts.

The Token Regarding the extent to which the token helped the users re-orient themselves after some lengthy side-tracking, two of the participants felt that it provided adequate information to get back into the session. The other two felt that while it did provide adequate information to rejoin the session after side-tracking, they would need the interaction log to get an indication of the current position in the overall sequence of events. At a normal point during the session (i.e. after no side-tracking), all participants feIt that the token provided enough information to enable them to know what to do next in the session. All participants stated that the token represented the locus of control of the session, and was very useful. One also stated that it was a very useful way of controlling interaction and monitoring the state of the session, and one stated that it was critical to understanding whose message passing sequence it was. This suggests that the token is a very successful conveyor of spatial information about the locus of control, and sequence of actions.

Modality Shifting All participants stated that they had no problems of mental translation of information types between the different views. They all felt they could mix the view information seamlessly. This strongly suggests that there was little or no modality shifting required by the interface. Any modality shifting that was required was clearly supported sufficiently well to make the player unaware of any mental processing required.

Level Shi~ting One participant identified a link between the 'Real World' and the Table View, and between the 'Problem World' and the Object Interactions Overview and Interaction Log. Another participant

identified, but did not state, links between the Real World, the CRCMQQ world, and the CRC session. The other two participants identified the CRC session, and the CRCMQO, and thought that all the worlds were represented in some respect. This does suggest some intuitive link between these levels of representation and the views in the prototype, even if the link is not consciously obvious to the player.

Discussion o7 Evaluation Results As a whole, the results are very positive, especially regarding the system of views and the token. Spatial memory load and cognitive processing were reduced by the interface in two ways. Firstly, the system of views was able to provide adequate useful information for the participants to carry out a (simulated) CRC card session. In essence, the system of views reduces spatial memory load by providing the required set of spatial information visually. This removes the need to visualise or otherwise record the information, and therefore removes the need to keep it in memory at any time. Each view provides information about a different aspect of the session, each of which has been identified as being a useful part of a session. Consequently, the views have almost eliminated the need for separate recording of event sequences or object diagrams. The exception to this is an Object diagram, which was not supported, and which was strongly requested by one participant. Secondly, the token reduces spatial memory load. It does this by indicating where the control of the session is currently situated. This removes the need to visualise the sequence of events in a session, which is bound to be a very abstract spatial visualisation, based upon the players' positions in a room, for instance. It also reduces the need to remember the visualised sequence. This process is reduced to the need to check one of the views for the red icon that is the token, and to click on the token for sequence information. Where the token does not provide adequate information, the interaction log can be used to obtain further details. Consequently, no memory is needed to determine the sequence of events or locus of control. The system of views seems to have removed the problem of modality shifting between different information presentation and thought types. This is essentially because the views provide a visual representation of all the information that is required,

with the exception of the interaction Iog, which is textual. However, this caused no problems in this trial with different types of thought patterns. It is possible that the indentation of the text, akin to that used in programming, helped to make this display more immediately accessible visually, reducing the amount of text that had to be read before reaching the part of current interest. The meaning of the lines indicating message passing in the interaction view was not absolutely clear. This did not seem to detract from the understanding of the interface generally. It was suggested that future iterations of the prototype could make these lines seIectable, so that they could reveal information about their message and position in the sequence of events. Future iterations of the prototype could also provide an object model, and information about an object's position in the object hierarchy. These points were mentioned in connection with the system's use as a teaching aid for OQ programming. However, they would also be potentially useful for early design sessions. In conclusion, the prototype has largely been successful in reducing the amount of cognitive processing and the spatial memory load required in conventional CRC card sessions, and especially in sessions conducted in the CRCMQQ.

Future Work Further Development of the Prototype The text chat feature was not fully imp!emented in the prototype, and itis anticipated that digital audio support would sit better with the approach of avoiding modality-shifting. Future versions of the prototype will support both techniques to allow experimental comparison. Improvements in the representation of the token and the users in the table view would be simple to achieve, possibly including more detailed visual information, such as the token's appearance changing depending on whether a message is pending or not, or the faces of participants changing according to their level (or lack of) activity. Work is currently underway to implement a new platform-independent prototype using Java.

A CollaborativeEnvironment for Role Playingin Object Space

Immersive Debugging In a sense, the act of debugging an executable program includes a certain amount of role-playing. When a programmer intervenes in the execution of the program to inspect or modify the values of variables or registers they are taking on some of the responsibilities of part of the program, a part which may not yet have been written. It is in the OQ paradigm that this is perhaps more cleanly realised, since state changes may be affected by sending messages rather than accessing the variables directly. Although CRCMOQ was initially aimed at supporting the role-playing of objects at the design stage, we might imagine interacting with a system which contains a proportion of 'live' objects, i.e, the system is partially completed. If we only have to send messages, then we don't really have to know whether the target object is live, or whether its role is being played by another participant. We aim to allow users to collaborate in an object space which encompasses interacting with their designs at all stages, from initial sketches through prototypes to fuIIyqmplemented systems. The difference in these cases would be the ratio of 'live' objects to those being role-played by designers. Another aspect of putting humans "into the loop" during debugging is that run-time errors may be caught and dealt with appropriately. When an object is sent a message that it doesn't know how to deal with, this usually causes a run-time error, We might allow the object to defer the handling of the message to a human operator who steps in to play its role temporaril}: A separate but related proiect, supported by an industrial CASE award from EPSRC and BT Research Labs, started in October 1996 with the aim of exploring the potential of role-playing in CVEs for supporting software design.

Systems, Languages and Applications. Meyrowitz ed. Reading, MA: Addison-Wesley, 1989; 1-6. 2. Wirfs-Brock R, Wilkerson B, Wiener L. Designing Qbject-Qriented Software, Prentice-Hall.1990. 3. Papert 8. M[ndstorms: Children, Computers and Powerful Ideas. New York: Basic Books, Inc. 1980. 4. Smith RB. The Alternate ReaIity Kit: an animated environment for creating interactive simulations. In: Proceedings 1986 IEEE Computer Society workshop on visual languages. Dallas, June 1986; 99-106. 5. Ungar D, Smith RB. Self: fhe Power of Simplicity. ACM SIGPLAN Notices 1987; 22(12):227-242. (Proceedings of OQPSLA '87) 6.

Finzer W, Gould L. Programming by Rehearsal. BYTE 1984; 9:187-210. 7. Laurel B. Computers as Theatre. (2nd ed) Reading, MA: Addison Wesley. 1993. 8. Benjamin I, Cooper M. Dramatic Interaction in Virtual Worlds. Proceedings of Second UK VR-SIG Conference, Reading. UK. 1st December 1994; l 7-24. 9. Johnson PM. Experiences with EGRET:An Exploratory Group Work Environment. Collaborative Computing I994; 1:87-107. 10. Brothers L, Sembugamoorthy V, Muller M. ICICLE: groupware for code inspection. In Proceedings of the Conference on Computer Supported Cooperative Work (CSCW '90). Los Angeles, California: ACM Press. 169-181. 11. Rodden T, Sommerville I. Supporting Cooperative Software Engineering. In Computer Supported Cooperative Work, S.A.R. Scrivener (ed), Ashgate Publishing. 1994; 207-222. 12. Rein GL, Ellis CA, rlBIS: a real-time group hypertext system. International Journal of Man-Machine Studies 1991; 34:349-367. 13. Coad R The Qbject Game, Qbiect International, Austin, Texas, USA. (Videotape) 1993, 14. Brooks LR. The Suppression of visualisation by Reading. QuartedyJournaI of Experimental Psychology 1967; 19:289-299. 15. Brooks LR Spatial and Verbal Components in the act of Recall. Canadian Journal of Psychology, 1968; 22:349-368. 16. Wilkinson N. Using CRC Cards - An Informal Approach to Object Oriented Development. New York: SIGS Books. 1995.

Reerences Correspondence 1, Beck K,Cunningham W. A Laboratory for reaching Obiect-Qriented Thinking. In QQPSLA '89, ACM Conference on Qbiect-Qriented Programming

D

C. Hand, S. Lingard, M. Skipper

and offprint requests to:

Chris Hand, Department of Computer Science, De Montfort University, The Gateway, Leicester LE1 9BH, UK. E-mail: cph@dmu, ac. uk