Tool for supporting distributed software engineering


Lap Chung Lam
Gaihung Lam


1 Goal and Motivation

The modern computer applications have become larger and larger in code size, and more and more complicated in algorithm and structure. The common practice of software development is done by teamwork. Each individual team member probably focuses on a particular module. Another trend is that an application or a module is developed and maintained by different programmers in its entire lifetime. Team members may be in the same geographical location or different locations. Teamwork requires cooperation. An individual team member probably is required to explain or walk through a piece of source code to other team members during the development of an application.


In this project we are going to develop a tool called Collaborative Source Code Documentation (CSD) system. CSD system provides application development team members an environment which they can sit together virtually to design, discuss, walk through source code, or do source code documentation on their applications, regardless of their geographic locations.


CSD system is not another conferencing software. The structure of CSD system may be similar to any other conferencing software. However, the main goal of CSD system is to provide an environment to make the task of distributed software development much easier.


CSD system allows users using voice and annotations to discuss a piece of source code regardless of their geographical locations. The CSD system automatically records the whole discuss session including voice and annotations, and store it into a web server as part of the application's document. Later on if anybody is interested in the same piece of source code, they can use a web browser to bring up the previous discussion session on the source code and play back the discussion session. In other words, CSD system is a remote conferencing application, and also a remote multimedia source code documentation system.


2 Related Work

Several collaborative computing applications have been developed and none of them meets our goal. They allow users to use text chat, voice, and video to communicate with each other over the the Internet.


CCF (Collaborative Computing Frameworks) and CVW (collaborative Virtual Workspace) are two excellent collaborative computing applications allow people do remote conferencing over the Internet. CCF mainly focuses on share applications and CVW focuses on share data. CCF is not able to record the process of a communication session, and CVW can only record the text conversation of a communication session.


Collaborative Computing Applications sometimes require highly synchronization. For example, when two users are discussing on a same program source code file, they should look at the same spot of the file. When one user does page down, the other users source code browsing window should automatically scroll down to the same position. If two users are navigating on the source code files with hyper links, when one user click on a link, both users should go to the same file. CCF does not have any problem on synchronization since it allows users share a virtual desktop, so that the users can work on the same applications at the same time. CVW allows users share data, but each user uses their own local application to open the data; therefore, there is no synchronization between CVW users.


Many other MBONE (multicasting backbone) applications have been also developed. The current popular MBONE applications are RAT (Robust Audio tool) for voice communication, VIC (Video Conferencing), Share WhiteBoard, and Network Text Editor. Multicast Multimedia Conference Recorder (MMCR) is an MBONE application too which can record and playback a session. However, all of the MBONE tools require IP multicasting support for many to may communication. Only small part of the Internet support multicasting, and this limits the practical usage of the MBONE tools.



Figure 1 Software Architecture of the CSD system

3 Software Design and Architecture

Platform independence is one of the primary goals of the CSD system. We want to develop an application, which can run under many different platforms. Therefore, Java becomes the choice of the computer language for the CSD system. CSD system consists of two applications, one is the server and the other is the client. Figure 1 is the software architecture of the CSD system. The server is for bookkeeping and organizing the communications between clients. The necessary tools that the client must have are whiteboard, code browser, and audio. The primary goal of this system is for the software developers to discuss their program source code over the Internet. The whiteboard is for them to annotate their source code, and the audio is for them to talk to each other in voice. The code browser allows them look at the same program source code.


3.1 Java Shared Data Toolkit

We use a Java library call the Java Shared Data Toolkit (JSDT) to develop the CSD system. The Java Shared Data Toolkit software is a development library that allows developers to easily add collaboration features to applets and applications written in the Java programming language. The most fundamental concepts of JSDT are Session and Channel. Before we explain what are sessions and channels, we will look at the definition of a Client. A Client is an object, which is part of a JSDT application or applet and is a participant in an instance of multiparty communication. A Client object can be the source or the destination of the data which is being exchanged in an instance of communication. A Session is a collection of related Clients that can exchange data via defined communications paths called channel. A session maintains the state associated with the collection of clients and their associated communications paths or Channels. A Channel is a specific instance of a potentially multi-party communications path between two or more Clients within a given Session. In order to send and receive data, a client must join the session, join the channel and register itself to receive data.


In the JSDT program model, any body can be a client or a server. You can send data or receive data to/from anybody else as long as you join the same channel. The CSD system has a dedicated client that acts like a central server. This server uses a directory session and a directory channel glues all other clients together, and provides them a central place to look for information.


The other reason why we choose JSDT is that JSDT provides a token mechanism which allow us to implement the synchronization of the CSD system easily. JSDT also supports both IP unicasting and IP multicasting. A JSDT application can be configured to run under IP unicasting protocol or IP multicasting protocol.


3.2 CSD server

The CSD server performs the following tasks:



The most important service of the server is to provide the clients with directory lookup. When the server is up, it creates a session call directory session and a channel called directory channel. Each client has to join the directory session when they connect to the server. The directory session has a data structure to keep information about all other sessions and clients. Each individual session has a data structure to keep information about the channels under its control.


The communication between the server and the clients is through the directory channel. The client can sent the following commands to the server: create session, delete session, join session, leave session, create channel, delete channel, join channel, leave channel. The client who wants to delete a session or a channel has to be the one who created it. A client can only create channels under the session created by him.


When a client logins and join the directory session, the server then send the information about all sessions and the channel of each session to the client through the directory channel. If any client creates a session or channel, the server will broadcast the information about the session or the channel to anybody else.


The server also needs to keep the state of each whiteboard and code browser. Whenever a client creates a whiteboard channel or a code browser channel, the server automatically joins the channel and registers itself to receive data from the channel. The server keeps the current contents of each whiteboard and code browser. When a client joins a whiteboard or code browser channel, the server sends the current contents to the client, and the client use the contents to initialize the whiteboard or the code browser.


3.2 CSD client

The basic tasks performed by a CSD client is



Figure 2: GUI of the CSD client after login. This client shows two sessions (left upper window). The first session has four channels and the second session has one channel. The right window is main working area.


Figure 2 shows the GUI of the CSD client application after login. During login, the server uses the system passwd file to authenticate the users. After a CSD client logins, the server send the information about all sessions and channels to the client, and the client displays the information on the left upper window. The user can use this window to create, delete, join and leave a session or a channel. The user will automatically join the sessions and channels created by him. Whenever he deletes a session (created by him), all channels under the session will be automatically deleted. If he leaves a session, he will leave all joined channels automatically. If any other client creates a session or a channel, the session and channel will be shown up on the window.


The right window is the main working area. Whenever a client creates or joins a session, a new working area is created. The user can switch to different working area by clicking on their tab. When the user leaves or deletes a session, the working area will be deleted. The working area is for displaying the tools of the corresponding channels. When the user creates or joins a channel, the tool for the channel will be displayed on its session's working area. The working area of Figure 2 shows three tools, audio, code browser, and witeboard.


After a client creates a code browser channel, he can use the code browser to open a source code file from the server machine. All other people who join the code browser channel can see the same file. The CSD system uses a token to synchronize the scrolling of the code browser. The token is crated at the server. If any participant of the code browser wants to scroll the code browser up or down, he has to require the token from the server first. As soon as the mouse button is released, the token is released. The synchronization guarantees every participant looks at the same spot of the file.


Only the code browser channel creator can initiate an annotation session on the source code. He has to pick a region of the source code first by highlighting it, and then clicks on the annotation button of the code browser. A whiteboard channel is created and all participants automatically join the whiteboard channel. The creator needs to click on the record button of the whiteboard to begin recording the annotation and clicks on the save button to save the annotation on the local disk. Later he needs to ftp the annotation file to the server.


The minimum required channels for the CSD system are voice channel, annotation whiteboard channel, and a source code browsing channel. The optional channels are shared web browser, chat, video, and network editor. We will develop the optional channels if we have the time. According to my knowledge, there is no share browser exists yet and we still do not know how to do this. Our primitive idea is to use an excellent Java HTML rendering engine called ICE browser to implement our own browser so that we can intercept all users' keyboard and mouse event and broadcast the events to other participants.


Figure 1 shows three clients, one "Directory Session" and two Client created Sessions. Session 1 created by Client 1 has four channels and Session 2 created by Client 3 has three channels. Client 2 does not create any Sessions, but it joints both Sessions. Client 2 joints all Channels in Session1 and only joints one Channel in session 2.


3.3 Audio data

The audio data is in PCM format of 8000 Mhz, 16 bits and 2 channels. Therefore, the worse case is that each voice channel participant has to send out 8000*2*2=32000bytes each second. To reduce sound delay, a sound packet is sent out every ¼ seconds, which is 8000 bytes of data. Currently, we cannot find any suitable Java sound compress library for our system. The existing Java GSM encoder and decoder implementation is for converting audio file formats. We need a Java GSM encoder and decoder for real time audio data. We need more time to do study on this subject. Therefore, we use silence detection to reduce the network traffic at the current stage of the CSD system. In the future, we will implement the GSM encoder and decoder in Java for our need, and get rib of the silence detection.



Figure 3: GUI for annotation playback.


3.3 Annotation file format

Audio data packets and whiteboard data packets come in asynchronously. We record the packets as Java data object into an annotation file in the order they come in. Current implementation does not record the time stamp of each packet. Therefore, during playback, the audio data and the whiteboard data are played continuously without any time gap between each data packet. In the future, we will add a time stamp to each data packet before they are recording into the annotation file.


Figure 3 is the GUI of the annotation playback tool. In the future, we will add fast forward, fast backward, pause, and stop functionality to the application.


4 Performance

The CSD system is easy and convenient to use. The only performance concern is the bandwidth for audio data. Though we use linear encoding for our audio data now, the sound quality and performance is excellent. With silence detection, there is not delay for audio data. We believe that the audio performance will be much better after we add the GSM encoding and decoding. The only problem we have now is the file size of the annotation information. Since we do not do any sound compression, the worse case of the annotation file is 2 Mbytes per minute. This problem will be gone after we implement the GSM in Java.


5 Future work

In the future, we will develop the GSM encoder and decoder for the CSD system, add text chat and web browsing tool. We will also add fast forward, fast backward, pause, and stop to the annotation playback tool. Editing function will be added to the whiteboard.

6 Conclusion

The CSD system is a convenient tool for remote documentation and discussion of software program source code. It can be run under any platform which supports Java.


Reference

http://cvw.mitre.org/

http://emily.mathcs.emory.edu/ccf/

http://java.sun.com/products/java-media/jsdt/