Towards Computer-Supported Concurrent ... - Semantic Scholar

4 downloads 0 Views 159KB Size Report
John Riedl, University of Minnesota. 1. ... P. Dewan & J. Riedl ...... S. Horowitz, J. Prins, and T. Reps, Integrating Non-Interfering Versions of Programs, ACM ...
Towards Computer-Supported Concurrent Software Engineering Prasun Dewan, Purdue University John Riedl, University of Minnesota 1. Introduction A software engineering task such as design, programming, debugging, testing, and inspection typically requires the concurrent participation of multiple users, possibly geographically dispersed. However, traditional software engineering environments provide limited support for enabling concurrent software engineering. For instance, they do not allow multiple users to concurrently debug code together using separate workstations. This problem is not unique to software engineering since traditional computing systems have not been designed to enable collaborative work1. It is a particularly serious problem in software engineering since software engineering costs are constantly increasing as a percentage of the cost of large systems and research has shown that the cost of interaction among team members is a significant part of the total cost of these systems2. Environments with support for improved interaction can allow software engineering to be performed more concurrently, potentially substantially decreasing these costs. Therefore, we have developed a new experimental software engineering environment called FLECSE (FLexible Environment for Collaborative Software Engineering) to support concurrent software engineering. In this paper, we motivate, describe, and illustrate the main components of FLECSE, thereby providing an initial answer to the following fundamental question: In what ways must a traditional software engineering environment be extended to allow software engineering tasks to be carried out more concurrently? A definitive answer to this question requires several iterations of (i) identifying concurrent software engineering scenarios, (ii) developing an environment that supports these scenarios, (iii) experimenting with the environment in controlled settings, and (iv) testing the environment in the field. We have carried out mainly steps (i) and (ii) of a preliminary iteration of this process, so our answers to this question are not yet ideal. However, we believe our work is a necessary and important step towards practical environments for supporting concurrent software engineering. In the remaining discussion we will examine five important themes of concurrent software engineering: Tools: We will discuss specific software engineering tools for supporting concurrent software engineering. We will discuss both extensions of existing tools and new tools that have no counterparts in the single-user case. This research was supported in part by National Science Foundation grant IRI-9015442, in part by a grant from the Software Engineering Research Center at Purdue University, a National Science Foundation Industry/University Cooperative Research Center (NSF Grant No. ECD8913133), in part by a grant from Purdue Research Foundation, in part by the University of Minnesota Graduate School, and by equipment from Project MinneMac, and Project MinNext.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

2

Concepts: We will discuss tool-independent concepts required to support concurrent software engineering, most of which are also applicable to other concurrent work. Lifecycle: We will discuss how the various phases in the software lifecycle can be made more concurrent. Integration: We will discuss how FLECSE concepts and tools can be used together to perform a single software engineering task concurrently. Sharing: We will motivate and discuss multiple levels of sharing in concurrent software engineering. The next sections introduce the ideas of collaborative software engineering through an example using the tools we have implemented in FLECSE. The ideas are introduced in order of increased sharing, starting with a distributed version control system, and finishing with a distributed program editor. Sidebars discuss other new software engineering technology that supports concurrent software engineering and implementation approaches for smoothly migrating from current single-user tools to a fully collaborative environment. 2. A Scenario Imagine collaborative engineering of a program for manipulating matrices. The program consists of a functional module, which supports matrix addition and multiplication; an I/O module, which supports reading and writing of matrices; a main module, which processes user commands for manipulating matrices; and an interface module, which defines the interfaces between these modules. Engineers Alice, Benu, and Chou are together responsible for engineering these modules. They have together written an initial version of the interface module, and separately written and tested initial versions of the functional, I/O, and main modules, respectively. Though they are working closely together on the project, Alice works from the University of Minnesota, Benu from Purdue University, and Chou from the University of Florida. The following sections of the paper use this simple scenario to illustrate and describe the FLECSE tools. Each of these sections introduces a new set of FLECSE tools, describes the novel concepts implemented by the tools, and illustrates and motivates these tools and concepts by showing how they help the engineers carry out the next phase of their task. In particular, these sections illustrate: (i) distributed but private coding and testing of initial versions of modules using the FLECSE distributed version control system and existing single-user text editors; (ii) collaborative debugging of the complete program using the FLECSE multi-user command interpreter, teleconferencing tool, and multi-user debugger; (iii) collaborative redesign of the program using the FLECSE inspection tool; and (iv) collaborative recoding of a module using the FLECSE multi-user program editor. We have chosen a simple software engineering scenario so that we can include it completely in this paper. The scenario explicitly shows collaborative technology in use, hinting at the power of multi-user tools. Most of the details of the scenario are worked out for the simple two-user case, but all of the tools described here work for three or more users also. Distributed Access to Software Artifacts and Tools[Sidebar 1] One of the advantages of concurrent software engineering is that the software engineers can work together effectively despite being geographically separated. In theory, concurrent software engineering methods should be

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

3

location-independent if the engineers are connected by a common network. In practice, however, they can be location-independent only if the engineers can efficiently access the various collaborative software artifacts and tools from distributed locations. This section discusses various solutions to the distribution problem, and briefly considers their suitability for software engineering. One approach to distributed software engineering is to create a single copy of the shared data at a single site and use remote login facilities to access the data. However, our experience shows that the cost of remotely editing files is intolerable when, for instance, a user at Minnesota remotely accesses Purdue files. The problem is that the remote login connection must transmit data across the wide-area network for each character typed by the user. Instead of remote login, a distributed window system, such as X can be used for remote access. A distributed window system offers a more flexible interface than the teletype-based remote login facility. However, like remote login, such a system must transmit all input and output across the network. Moreover, input events such as movement of the mouse can occur frequently and output can be graphical and hence large. Thus, both remote login and distributed window systems do not offer acceptable response times when used over wide-area networks. An alternative is to create duplicate copies of the data at each site so the data can be accessed locally. However, this approach requires the overhead of keeping these copies consistent. Moreover, it does not provide any concurrency control. Furthermore, it requires that the tools that manipulate these files understand file names in multiple name spaces. Distributed database management systems automatically create replicated copies, keep them consistent, and offer concurrency control. However, these systems have not been designed for wide area networks or for storing software engineering artifacts such as syntax trees. A promising approach is to create part of the application state at the local site and provide local processing of this state. This approach is adopted by several different kinds of distributed systems. The Shadow Editing system3 provides a local text editor that caches the remote file and sends updates to and receives updates from a remote server. The Andrew File System (AFS)4 keeps a local cache of accessed files and writes them back to the remote site when they are closed. Cache consistency is ensured through locks and callback routines that ensure only one copy of a file can be updated. The VGTS5 distributed graphics system allows remote clients to invoke high-level graphics requests and converts them locally into the lower-level, and hence more data intensive, screen updates. Our work extends this idea by creating the entire user-interface state locally and providing a local agent for manipulating the state.

3. Distributed Version Control and RCSTool The sidebar on distributed access discusses various approaches to the problems posed by distributed access to shared software engineering artifacts and tools. FLECSE addresses these problems by: (a) storing all software artifacts such as source files, executable modules, test data, and inspection annotations at a single autonomous

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

4

site , thereby providing a single naming scheme for all artifacts; (b) executing all tools such as the debugger that access these artifacts at the same site; and (c) replicating the user-interface component of a tool at the site of each engineer and caching the tool state in these replicas, thereby providing the engineers with local response. We illustrate this approach using a new tool, RCSTool, which allows users to efficiently access RCS operations such as check-in and check-out (see sidebar on coordination) and the versions they manage from distributed locations. RCSTool provides a visual, multi-user, distributed interface to RCS programs (Figure 1). It displays the state of the versions checked-in to an RCS directory to all users interacting with it and allows them to perform several operations on these versions including check-in, check-out, and edit. Continuing with the example, assume that all software artifacts such as RCS directories are stored at Purdue and Alice and Benu (who are interacting from University of Minnesota and Purdue, respectively) have invoked an edit operation on the current RCS version of the interface module (Figure 1). The RCSTool is executed at Purdue but the user-interface components of the two users run at the local sites and cache the tool state. In particular, each of the text editors executes at the local site, caches the file being edited at the start of the editing session, and sends the updated buffer to the tool at the end of the session. RCS ensures that only one of them can modify a file at any time. RCSTool gives geographically dispersed software engineers the benefits of a single naming scheme, a single copy of all files, concurrency control, and local response. It also provides the facility of automatic notification. When a user changes the status of a file, the status is automatically changed on the displays of all users. In the absence of this facility, engineers interested in receiving changes would be forced to poll the tool for these changes or the engineers making these changes would be forced to manually send mail. Coordinating Concurrent Software Engineering[Sidebar 2]

Figure 1: RCSTool and Distributed Private Editing. Benu and Alice have each used RCSTool to open an editor window on the interface module. RCS will only allow one of them to update the file when they are done editing. -By a site, we mean a set of computers with a network file system.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

5

Concurrent software engineering requires a method for coordinating the activities of the engineers to ensure that they do not make inconsistent changes. However, traditional software systems provide few tools to coordinate group software engineering. Typically, these tools consist of mail systems, which allow users to communicate status and other information, and version control systems such as RCS6, which ensure that inconsistent changes are not made to shared objects. These two systems represent two extremes in the degree of control provided to coordinate a task: Mail systems provide no control and offer only communication among users who are manually responsible for controlling their activities. Users are free to, for instance, edit the same file simultaneously, and are responsible for communicating with each other to ensure that changes are not inconsistent. Version control systems, on the other hand, lock entire files to prevent other users from modifying them. Recent works on concurrency control and mail systems attempt to provide middle grounds between manual communication and file locking. The long-transaction model, also called the engineering transaction model, has been proposed as an alternative to the check-in/check-out model of traditional version control systems to better support concurrent software engineering7. Under this model, software engineers perform a transaction on a configuration of files rather than individual files, thereby being able to atomically change a set of related files in a repository. Unlike traditional database transactions, but like traditional revision control transactions, these transactions create persistent workspaces of the data elements modified while they are executing and new persistent versions of these elements when they commit. A long transaction can create child transactions by deriving new workspaces from an existing workspace, each of which commits changed values to the workspace of the parent transaction. As a result, it is possible, for instance, for a team of developers to start a long transaction that starts subtransactions for each developer. Each of these leaf-level transaction commits to the workspace of the parent transaction and not the repository, thereby allowing the developers to share partial results before they commit them to other software engineers such as the testers who can access only the repository. In comparison to the check-in and check-out model, the long transaction model promotes concurrency since it allows sharing of partial results, thereby keeping data locked from engineers for a shorter time period. Information Lens8 extends the facilities of traditional mail systems by supporting semi-structured messages and a set of rules that can be used to filter messages received from others. It associates each message with a message type, and allows a message type to inherit the fields and rules defined by an existing type. It can be used in a concurrent software engineering environment to, for instance, classify messages into ‘‘requests’’ and ‘‘notices’’, and further divide the former into ‘‘file lock requests’’ and ‘‘inspection meeting requests’’ and the latter into ‘‘file lock notices’’ and ‘‘inspection meeting notices’’. It can also be used, for instance, by a programmer to define a rule that automatically unlocks a file in response to ‘‘file lock’’ request. Thus, Information Lens can make it easier to automate part of the task of communicating information among collaborating software engineers. FLECSE complements these works by supporting fine-grained locking, sharing of a hierarchy of partial results, and automatic communication of results to collaborators interested in them, as shown in the section on concurrent editing.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

6

4. Concurrent Debugging with MShell, MDebugger, and TeleConf Chou agrees to test the commited versions of the modules of the program, while Alice and Benu focus on other tasks. He compiles the program using these modules, tests it, finds that the output is erroneous, and concludes that the fault is perhaps in the functional module. So he decides to seek the help of Alice, the author of the module. At this point, the two engineers decide to collaborate using the the FLECSE tool, MShell, a multi-user command interpreter.

MShell is an extension of a single-user command interpreter that supports three addi-

tional concepts: First, it allows multiple users to interleave their commands. Second, it allows multiple users to share the responses to the commands entered by the various users. Finally, it allows users to control how the execution of independently submitted commands is serialized by submitting command transactions and manipulating the transaction execution queues. Let us continue with the example to further illustrate some of these concepts. Chou uses MShell to enter and execute a command transaction that displays the input file and executes the test program. Both users see the transaction and its output (Figure 2) and notice the error. Neither of them individually can discover the bug, so each of them starts a teleconference using the FLECSE tool TeleConf, which enables users to talk to each other over a network using audio capabilities in their workstations.

TeleConf records, transmits, and plays live

audio in real-time, so the users can discuss operations they are executing in the multi-user interface as they occur. Chou argues that the MShell session proves that the mistake is in the functional module, while Alice asserts that her tests prove that the functional module works fine, so the mistake must be in the main module. They agree to work together to solve the problem, so they start a session with MDebug, the FLECSE multi-user debugger, which is an extension of an existing single-user debugger. Like MShell, it also supports the concepts of command interleaving, output sharing, and user-defined transactions. Figure 3 illustrates the interaction sequence that occurs next. In this figure, Chou’s and Alice’s window show the initial and final parts of the collaboration respectively, and uninteresting commands have been elided. Like other public windows supported by FLECSE, these windows can be scrolled independently by different users (Figure 3). Chou uses MDebug to put a breakpoint just before the matmult call to demonstrate to Alice that the

Figure 2: Concurrent Command Execution. Alice and Chou use MShell to collaboratively run their program. The command transactions entered by Chou and the resulting output are shown to both users.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

7

arguments are set up correctly before the call, and that the result comes back incorrectly (command transactions 2, 3, and 4). Alice suggests they try again (command 5). Chou prints the parameters inside matmult and points out to Alice through TeleConf that they were passed properly (command 6). Alice puts a break point in the loop of matmult (command 7), steps through the loop inside matmult three times (commands 8, 9, and 10), and notices on the third time that the result is incorrect. Alice immediately prints the values of the original matrices, notices that B has changed (selected region, command 11), and asks if B could somehow overlap C in the arguments. Chou shows her that he allocates the same memory for the input matrix B and the output matrix to save storage (selected region, command 2). He argues that a functional module should not do an incremental assignment to the output matrix. Instead it should do a complete copy at the end of the computation. Alice argues that the main module should not have tried to save space. The module specifications do not clearly state storage allocation rules, so the programmers are at an impasse and decide to suspend their synchronous interaction and think more about the problem.

Figure 3: Concurrent Debugging. Chou and Alice are debugging together, intermingling commands freely. Note that they have independently scrolled to view different parts of the output.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

8

This example illustrates the benefits of supporting multi-user debuggers and command interpreters in a concurrent software engineering environment. In the absence of these tools, the engineers would have been forced to try to solve the problem individually, or send each other mail messages describing their debugging sessions, or hold a physical meeting while sharing a single workstation. The first option could have resulted in duplication of effort and not lead to a solution since the problem was caused by interaction between modules developed by different engineers. The second option requires the engineers explain rather than simply demonstrate their experiences to other engineers. The third option is at best serial since the engineers have to share a single physical workstation and at worst very costly or impossible since the engineers may be geographically dispersed. 5. Collaborative Software Inspection (CSI) Alice and Chou now decide to use CSI, the FLECSE collaborative software inspector, to come to an agreement on an appropriate solution to the problem. CSI supports concurrent software engineering in three ways. First, CSI’s asynchronous support enables the engineers to do as much work as possible in parallel. The result of the asynchronous phase is an integrated fault list. Second, CSI’s synchronous support enables the engineers to work together effectively in a distributed meeting. During the meeting the faults are discussed in estimated order of importance. One of the meeting products is a set of formal goals for parallel work after the meeting completes. Third, CSI’s use of multimedia supports both asynchronous and synchronous activities. The Annotator helps users comment more efficiently on software products, by supporting voice annotations attached through hyperlinks to software documents. During CSI meetings, distributed participants converse with TeleConf, which supports live audio teleconferencing through the user’s workstation. Continuing with the example, structured asynchronous annotations allow Alice and Chou to make their arguments privately without bothering each other with them (Figure 4). Once they are ready to present their arguments, they can commit their annotations to make them visible to other programmers. At this point, the collaborative software inspection tool also presents an integrated list of faults, sorted by estimated severity (Figure 4). After reading each other’s annotations, the programmers arrange a software inspection meeting, inviting Benu to act as moderator. Even though they are working in different parts of the country, they can interact $ through their workstations, using TeleConf for discussion. The collaborative software inspection tool has hyperlinks from the integrated fault list into the program, and from lines of the program to the full annotation describing the fault. The programmers quickly jump the hyperlink to line 6 of the main routine in a shared code browser, and discuss the fault through TeleConf. Benu agrees with Alice that it would be too expensive for matmult to make copies of the entire array, and hence that calling the function with the result matrix overlapping one of the source matrices is an error. Chou reluctantly agrees, so Benu moves fault (1) to a disposition list with the further annotation that Chou will fix the problem.

$ We have not yet tested TeleConf across wide-area networks.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

9

Figure 4: Collaborative Software Inspection. During the asynchronous phase, each user has a window showing the code they are commenting on, and an annotation window for structured textual annotations. During the synchronous phase, an additional collector window is visible to all users showing the integrated list of all faults. The programmers next consider fault (2), together looking at line 9. Chou points out that this is likely to be a common bug. He suggests that Alice test for at least the easy aliasing case in which the result array is identical to one of the source arrays. Alice agrees, so Benu moves fault (2) to the disposition list with the annotations that Alice will add code to check for this case, and will modify the documentation to indicate the restriction. Notice that the programmers working together came up with a solution that was better than they were likely to achieve separately, because they had two different views of the problem. The main programmer saw the problem from the perspective of a user of the subroutine, while the matmult programmer saw the problem from the perspective of the subroutine programmer. The user was most concerned with ease of use, while the subroutine programmer was also concerned with efficiency of implementation. The final program benefits from both views. Four main lessons can be learned from this example: First, mixed synchronous/asynchronous collaboration gives users the flexibility of easily moving between working in parallel on independent tasks or collaborating on a group task. Purely synchronous or purely asynchronous tools make this transition difficult since they require users to switch tools and possibly recreate session state. To illustrate, assume that CSI supported only synchronous collaboration. To communicate asynchronously, Alice and Chou would have been forced to use an existing singleuser editor and then transfer the information to an annotation window. Conversely, if CSI supported only asynchronous collaboration, then to converse synchronously the engineers would have been forced to transfer the annotations to a tool such as talk tool that supports synchronous collaboration. Second, synchrony should be orthogonal to media, that is, synchronous and asynchronous interaction should be supported not only in textual communication but also in audio communication. Otherwise engineers are forced to choose the wrong medium or the

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

10

wrong synchrony. For instance, if FLECSE had supported only synchronous audio, then Alice and Chou would be forced to make all annotations textually, which is often more tedious than making audio comments especially when the annotation has to address complex structural and semantic issues9. Third, a concurrent engineering tool must support permanent group meeting products, thereby making it easier for the team to follow through on the decisions reached in the meeting, or for an engineer to join an ongoing team effort. Finally, these products must capture varying amounts of the meeting details to allow engineers to look at only those aspects of the meeting record that are of interest to them. For instance, the CSI meeting products include the annotation and the final fault disposition list (Figure 4). The manager of the team can look at the disposition list while a new engineer joining the team can look at each individual annotation. As shown in Figure 4, CSI displays each annotation in a separate window. An alternative, and perhaps more intuitive, approach to annotations is supported by the PREP editor10, which arranges annotations made by different users in different columns, thereby providing an easy method for identifying the contents and authors of all annotations attached to some section of the document. PREP is asynchronous, that is, allow only one user to add/view an annotation at any one time. ICICLE11 allows multiple users to meet at a central site to discuss a document, all sharing a view of a set of annotations, thereby streamlining the meeting and reducing the need for paper documents. FLECSE extends the idea of centralized software inspections to support distributed software inspections, multiple meeting products describing the results of the meeting at different levels of detail, and annotations in both the synchronous and asynchronous collaboration mode. 6. Concurrent Editing and MEdit Continuing with the example, the engineers now discuss the user-interface and decide that the program should prompt the user when it is used interactively. Since they are very near the project deadline, they decide that Chou should make the necessary changes to the interface and main modules while Alice and Benu concurrently change the I/O module to accommodate this new feature. Alice and Benu concurrently modify the I/O module using MEdit, which is an editor with a limited understanding of the structure of the C programming language. Users operate on program structures such as lines or functions. Like traditional version control systems, MEdit allows a user to (a) modify a copy of a program structure and later commit it and (b) lock the copy until it is committed. Moreover, like engineering transactions (see sidebar on coordination), it allows users to share uncommitted values or partial results. In addition, it supports four new concepts: First, it offers an editing interface to compose transactions. A user makes a new (logi$ cal ) copy of an unlocked program structure by executing the first editing command such as ‘‘insert char’’ that attempts to change its value and commits it by executing the editor ‘‘accept’’ command. Second, it supports finegrained concurrency control by supporting copying, locking and commitment of functions and lines. Third, it supports sharing of not only values of program structures but also user-interface state such as selections and $ Like other FLECSE tools, MEdit makes a physical cached copy when a user starts the editing session.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

11

scrollbars. Finally, it supports coupled interaction, that is, it allows users to request that their displays be automatically updated when the state they share is changed by one of them. Continuing with the example, Alice and Benu use MEdit to concurrently edit the I/O module. They set the locking granularity to C functions, disable coupling, and start editing the output and input functions, respectively, which makes new locked logical copies of these program structures. Since they have requested uncoupled interaction, changes made by each engineer are not transmitted to the other (Figure 5). Soon Benu finishes his changes to the input function and commits them. He then tests the committed version of the I/O module (which does not include Alice’s changes) and satisfies himself about the correctness of his changes. He can now help Alice finish her changes to the output function. Therefore, the two engineers request MEdit to (a) allow sharing of partial results, thereby allowing Benu to join Alice’s transaction; (b) enable coupling, thereby allowing them to automatically receive each other’s changes; and (c) make lines the granularity of locking, thereby allowing Benu to insert comment lines into the input function while Alice modifies the body (Figure 6). Once Alice finishes her work, she checks Benu’s comments for consistency with her changes, finds problems with the wording of the comments, connects their selections and mouse pointers together using flexible coupling mechanisms, selects and points to the inconsistent portions for Benu instead of describing them to him, get his approval, fixes the problem, and commits all of the changes shown on her display— both the ones she made and the ones she received from Benu through coupling. They now go through a few iterations of debugging and changing the code using MShell, MDebug, and MEdit until they satisfy themselves that it works. To illustrate the benefits of MEdit and the associated concepts, consider how the engineers would have concurrently modified the I/O module using a traditional environment. Since traditional systems do not support fine-grained concurrency control, they would have been forced to create separate versions of the module and

Figure 5: Concurrent Private Editing of Different Procedures. Benu and Alice are editing different functions from the same file, using MEdit locking at the level of functions. Since the programmers are working independently, uncommitted changes are not being transmitted in this session.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

12

Figure 6: Concurrent Public Editing of a Procedure. Benu and Alice are now editing the same function, using MEdit locking at the level of lines. Since they are working together closely, their coupling is set to show incremental updates. independently edit them. This scenario has two serious disadvantages: First, it does not prevent the two engineers from making conflicting changes, thereby requiring a merge process at the end of the editing session. In general, the merge process requires human intervention though in some cases it can be carried out automatically by a tool12. Second, it requires that the engineers divide their tasks at version creation time, thereby requiring, for instance, that Benu wait for Alice to finish her editing session before he can do further work. MEdit addresses these two problems by providing engineers facilities for incrementally preventing certain kind of inconsistencies rather than curing them later during a costly merge process, and by dynamically reassigning tasks thereby eliminating potentially costly waits. In particular, fine-grained concurrency control prevents engineers from making concurrent changes to the part of the module (line or function) that is locked, coupling allows them to incrementally discover conflicting changes among related parts of a module, and sharing of userinterface state such as selections and mouse positions allows them to incrementally resolve these changes without requiring the overhead of a physical meeting or another tool such as CSI. Moreover, coupling also allows the engineers to dynamically reassign their tasks since it allows them to see each other’s editing changes. The notion of fine-grained concurrency control is consistent with the notion of nested transactions supported by engineering transactions (see sidebar on coordination). In particular, values commited to MEdit can later be commited to a configuration by a parent transaction. For instance, after Benu and Alice have terminated their concurrent editing of the I/O module, they can commit the module to RCS. Implementing Collaborative Software Engineering Tools [Sidebar 3] Three complementary approaches have been used to implement collaborative software engineering tools. Manual Implementation: The tools are written from scratch. While this approach gives tool programmers the flexibility of designing all aspects of the tools, it makes the task of implementing them extremely difficult. Most collaborative software engineering tools that have been experimented with such as ICICLE (see section on CSI) have been implemented using this approach. The implementation of collaborative software engineering tools is difficult since typically these tools must implement several collaboration tasks such as multiplexing input, demultiplexing output, providing concurrency control, and coupling user input in multiple media.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

13

Generic Wrappers: A generic wrapper program such as a shared window system13 is used that handles all collaboration tasks of a single-user tool. The wrapper merges all keystroke events into a single stream for the single-user tool, transmits screen commands to all users, and provides concurrency control. This approach does not require any changes to existing single-user programs. However, wrapper programs do not meet the requirements of several software engineering tools for two reasons. First, since they do not know the structure of the information displayed by a tool, the only concurrency control mechanism they can support is coarse-grained floor control, which serializes interaction. Second, since they do not know the structure of the user-interface state, they can only allow complete or no sharing of this state. For instance, they cannot allow users of MDebug to scroll to different parts of a program (Figure 3) or users of MEdit to privately edit procedures (Figure 5). Flexible Framework: A flexible framework allowing programmers to easily implement a variety of multiuser applications is used. We have used this approach in the implementation of FLECSE, by implementing it using a framework consisting of the multi-user Suite14 and SuiteSound systems15. The framework integrates the two approaches described here. Multi-user Suite knows the structure of displayed data, and uses this knowledge to provide a default editing-based collaboration scheme that automatically handles concurrency control, coupling, and other collaboration functions of a multi-user application and allow programmers and end-users to tailor this scheme by changing, for instance, the granularity of concurrency control. SuiteSound (see the multimedia sidebar) provides abstractions for incorporating audio in multi-user applications. This approach supports the use of existing tools by allowing programmers to write wrapper programs around existing single-user programs, such as a debugger, that use the facilities provided by Suite and SuiteSound. We have been very successful in using this approach to implement FLECSE. The framework allowed the complete implementation of FLECSE to take only about two years—each tool was implemented typically by a single graduate student, who spent a substantial part of his time learning the infrastructure, as part of a semester-long class project. The framework, however, does not support the implementation of arbitrary multi-user tools including tools that create complex graphics. We expect all three approaches to be used for creating multi-user software engineering tools: a generic wrapper for using existing tools in a highly collaborative meeting mode, a flexible framework for implementing tools such as the ones provided by FLECSE, and manual implementation for tools that need to display complex graphics.

Multimedia Support[Sidebar 4] Multimedia support can enhance collaborative software engineering by helping engineers work together in a distributed environment using the same media they use in a face-to-face, centralized environment. It can include audio and video annotations, audio and video teleconferencing, and support for gestures in distributed meetings. Researchers have developed authoring systems that provide multimedia support in creating, and editing of multimedia documents. For instance, MediaView is an editable multimedia publication system that supports the cut, copy, and paste operations to text, audio, images, and video16. PREP (see section on CSI) allows users to attach audio annotations to documents. These systems demonstrate that media-rich documents can enhance

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

14

asynchronous communication among collaborators. Other systems have applied digital audio and video to synchronous collaboration. For instance, the MERMAID system is designed for collaborative decision-making with multiple remote participants17. Data, voice, and video are transmitted using N-ISDN channels with 64Kpbs per channel. The voice and data use one B-channel and video the other. Users can talk freely, with voices mixed and transmitted to all users simultaneously. Synchronization, routing, and distribution are done separately for voice, video, and data. This approach allows all three to run at high speeds, but makes the synchronization of the media more difficult. Researchers are also focusing on developing sharable audio servers for supporting multimedia applications. Angebarnndt et al18 describe a client-server model that uses an audio server for supporting shared access to audio hardware, introduces a protocol that provides applications with a device-independent interface to the audio capabilities of the workstation (virtual devices), and provides primitives for synchronizing the various media components. Our work on multimedia support consists of the audio-based FLECSE tools and the SuiteSound server (see the implementation sidebar) used to implement audio support in these tools. It extends previous research in five main ways. First, FLECSE supports both asynchronous audio annotations and audio-based synchronous teleconferencing. Second, SuiteSound provides an object-based interface for building audio-based applications that integrate multimedia with traditional objects, thereby promoting simplicity and re-usability. Third, our work supports multimedia flows with multiple sources and multiple sinks, and several useful ways to merge or split the flows. Fourth, we are investigating methods of concurrency control that allow end-users to effectively control multiple multimedia streams at their workstations. Finally, we are performing experiments to measure the costs of different implementation strategies for multimedia systems on conventional operating systems. 7. Conclusions In this paper we have demonstrated the application of concurrent software engineering to a series of software engineering tasks to show concretely the potential for increasing the effectiveness of teams of software engineers working together. We illustrated some of the benefits of concurrent software engineering using a simple scenario in which three engineers develop a small program. The various tools we described have even more potential in more complex scenarios. Three specific benefits that scale up are support for distribution, flexible synchronization, and flexible meeting products. All of these tools allow distributed software engineers to collaborate with each other without holding meetings. As the complexity of the task and the size of the team increases, it is more likely that the engineers would be distributed and thus benefit from these tools. Moreover, these tools allow engineers to collaborate both synchronously and asynchronously, thereby allowing them to switch between close and loose collaboration. As the number of logical subtasks in a team task gets larger, it is more likely that a particular engineer would need to switch between close and loose collaboration with the other members of the team. Support for both asynchronous and synchronous collaboration could also enable engineers to maximize collaboration despite differences in work styles or time-zones, which can be expected to arise more in a larger team. Finally, CSI produces meeting records that capture varying amounts of the meeting detail. As the variety in the team increases, it is more likely that the team members would wish to know about different details of the meeting.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

15

In this paper, we have described only a subset of the FLECSE tools. Some of the FLECSE tools we did not discuss are SplitTool, a tool that provides engineering transactions for concurrency control, extended for more interaction; MAtac, which allows multiple users to test which parts of a function are covered by test data; and ^ Nav, a tool that allows engineers to collaboratively navigate among makefile targets, the list of source files on which the targets depend, and the procedures in the source files. It is in the spirit of hypermedia systems such as ABC19 which arrange the various software artifacts such as documentation, programs, program statements and diagrams in a graph, attaching cross links called ‘‘hyper links’’. Together, these tools increase concurrency in all phases of the software engineering lifecycle. Table 1 summarizes the applicability of the FLECSE tools to various phases of the software lifecycle. Many of the tools are applicable in several different phases. For instance, CSI can be used to inspect requirements, design documents, or code. We see several important areas for future work in concurrent software engineering in general, and FLECSE in specific. It is important to investigate additional technical issues such as collaborative undo/redo. Moreover, it is important to address other kinds of tools that have the potential of decreasing the cost of concurrent software engineering such as project management tools. Furthermore, FLECSE is based on a relatively unintegrated set of

Requirements RCSTool

Design

Code

X

X

Debug/Test

MShell

X

X

X

X

TeleConf

X

X

X

X

X

X

MDebug CSI

X

X

X

Annotator

X

X

X

SplitTool

X

X

MEdit

X

X

MAtac Nav

X

X X

X

Table 1: FLECSE Collaborative Tools and the Software Life Cycle ^Makefiles are Unix files that describe how to build a working system from a set of files. The targets are the executable programs.

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

16

single-user tools. It would be useful to explore how integrated environments such as PECAN20 could be extended to support concurrent software engineering. Finally, though we have performed some pilot experiments with the CSI tool, most of our work to date has been to demonstrate the feasibility of implementing and using the tools. It is important to do further experimental studies to evaluate the usefulness of these tools in particular and concurrent software engineering in general. In particular, it would be useful to identify which of the various work styles used in current organizations are consistent with this technology and thus characterise the behaviors of users who can be expected to use this technology. We hope this paper has given the reader a glimpse of the benefits collaborative technology can bring to software engineering. Our initial experience with CSI shows that making collaboration easy has the potential to produce synergy among a team. Different engineers bring different skills and perspectives to a problem. Helping them work together can improve their performance and the quality of their product. Structured interaction, multimedia support, concurrency control, caching of user-interface state and other techniques described and illustrated here have the potential of enabling engineers to work together concurrently more effectively, which is necessary to improve software productivity as teams become larger and team interaction becomes more of a bottleneck. Acknowledgments We thank the anonymous referees for their insightful suggestions towards improving our presentation. Brett Lane implemented MDebug, Gang Zhu implemented MShell, Vahid Mashayeki implemented CSI, Honghai Shen implemented MEdit, MAtac, and Nav, Anjali Srivastava implemented SplitTool, and Rajesh Bhatia and Honghai Shen implemented RCSTool. References 1.

Clarence A. Ellis, Simon J. Gibbs, and Gail L. Rein, Groupware: Some Issues and Experiences, CACM 34(1) pp. 38-58 (January 1991).

2.

Gene Forte and Ronald J. Norman, A Self-Assessment by the Software Engineering Community, Communications of the ACM 35(4)(April 1992).

3.

Doug Comer, Raj Yavatkar, and Jim Griffioen, Shadow Editing: A Distributed Service for Supercomputer Access, IEEE International Conference on Distributed Computing Systems, (June 1988).

4.

Mahadev Satyanarayanan, Scalable, Secure, and Highly Available Distributed File Access, IEEE Computer 23(5) pp. 9-22 (May 1990).

5.

Keith A. Lantz and William I. Nowicki, Structured Graphics for Distributed Systems, ACM Transactions on Graphics 3(1) pp. 23-51 (January 1984).

6.

Walter F. Tichy, RCS—A System for Version Control, Software—Practice and Experience 17(7) pp. 637-654 (July 1985).

7.

Gail E. Kaiser, A Flexible Transaction Model for Software Engineering, Proceedings of the Sixth International Conference of Data Engineering, pp. 560-567 (February 1990).

8.

T. Malone, K. Grant, F. Furback, S. Brobst, and M. Cohen, Intelligent Information-Sharing Systems, CACM 30(5)(1987).

9.

J. Galegher and R. E. Kraut, Computer-Mediated Communication for Intellectual Teamwork: A Field Experiment in Group Writing, Proceedings of the ACM Conference on Computer Supported Cooperative Work, pp. 65-78 (October 1990).

10.

Christine M. Neuwirth, David S. Kaufer, Ravinder Chandok, and James H. Morris, Issues in the Design of Computer Support for Co-authoring and Commenting, Proceedings of ACM Conference on Computer

P. Dewan & J. Riedl

Towards Concurrent Software Engineering

17

Supported Cooperative Work, pp. 183-195 (October 1990). 11.

L. Brothers, V. Sembugamoorthy, and M. Muller, ICICLE: Groupware for Code Inspection, Proceedings of the ACM Conference on Computer Supported Cooperative Work, pp. 169-181 (October 1990).

12.

S. Horowitz, J. Prins, and T. Reps, Integrating Non-Interfering Versions of Programs, ACM Transactions on Programming Languages and Systems 11(3)(July 1989).

13.

J.C. Lauwers and K.A. Lantz, Collaboration Awareness in Support of Collaboration Transparency: Requirements for the Next Generation of Shared Window Systems, Proceedings of ACM CHI’90, pp. 303-312 (April 1990).

14.

Prasun Dewan and Rajiv Choudhary, A High-Level and Flexible Framework for Implementing Multi-User User Interfaces, ACM Transactions on Information Systems 10(4)(October 1992).

15.

J. Riedl and V. Mashayeki, Continuous Media in Discrete Objects: Multimedia for Computer Supported Collaborative Work, Proceedings of 1992 Workshop on Multimedia Information Systems, (February 1992).

16.

S. Sakata, Development and Evaluation of an In-house Multimedia Desktop Coneference, IEEE journal on selected areas in communcations, (April 1990).

17.

Kazuo Watabe, S. Sakata, and K. Maeno, A Distributed Multiparty Desktop Conferencing System and its Architecture, Proceedings of the Ninth IEEE Annual International Phoenix Conference on Computers and Communications, (March 1990).

18.

Susan Angebarnndt, Richard Hyde, Daphne Luong, Nagendra Siravara, and Chris Schmandt, Integrating Audio and Telephony in a Distributed Workstation Environment, Proceedings of the Summer 1991 USENIX Conference, pp. 419-435 (1991).

19.

John B. Smith and F. Donelson Smith, ABC: A Hypermedia System for Artifact-Based Collaboration, Proceedings of the Third ACM Conference on Hypertext, (December 1991).

20.

S. P. Reiss, PECAN: Program Development Systems that Support Multiple Views, IEEE Transactions on Software Engineering SE-11(3)(March 1985).