Though the version control was an extra addition to this project, it benefited the project in many aspects. The version control was used to manage numerous files among several team members that had to have access to the files. Version control provided a centralized location of the most current and up to date files of the project. Version control was also developed for the purposes of backups. Backups were one of the greatest contributions to this project.
The method to manage files within the project was needed, because as many as five team members need to have access to the same files. At times the same file was being reviewed and edited by two or more people at the same time. In this version of the version control there is no easy means to check the differences between files. Many of the team members are fluent in UNIX, so they used the diff command in our to do this operation. Because version control lacked this operation the team members were required to do their own integration of their code into the version controls code.
Therefore the simplicity of the scripts and the ability to run the scripts from any directory on the system made it very easy to use the version control commands. Because it was of this easy, so the version control became the centralized area for the most current and working files for the project. A beneficial addition to this, was that version control also became the central location for maintaining backup copies of previous versions.
Backups of old versions of files and database records came in very handy. Doing a backup of any project or system is always a good practice to have. For this project there were three different types of backups that were made: version control backups, floppy disk backups and remote system backups. It turned out that all three of these methods were used through out the project.
Version control backups came in handy when integration of files did not work properly or team members accidentally delete portions of code. The easy and the safest way to get their modifications back was from version control backups. The second type of backup used was floppy disks. Many of the team members did a lot of their own work on remote systems and made modifications. Once they had working coded they brought the code back to the main system at Villanova University and tested it and integrated their changes, which then was put back into version control. So once again, just like the first form of backup, floppy disk backups were useful. The third form of backup made was remote system backups. This type of backup is good to have, specially if something happens the system which one is working on. It just happened that in the later stages of our project the team experienced several system difficulties: power outages, and damaged disk containing the user directories. So remote system backups proved to beneficial. Every night the entire project was down loaded to a IBM PC as well as disks of various team members.
Due to time restrictions, there was not enough time for an installation of a version of SCCS or time for all the team members to get familiar to such a complex application. Only main concepts of the SCCS software were captured and implemented in my version of the version control software. The following is a description of the SCCS software and a condensed description of the sub-commands with I modeled my version control software after. To see a detailed description of the sub-commands refer to Appendix B. If any one wants to see the source code, it can downloaded upon request.
The sccs command is a comprehensive, straight forward front end to the various utility programs of the Source Code Control System (SCCS). Many of the following sccs sub-commands invoke programs that reside in /usr/sccs (of most UNIX based systems if it was installed). Many of these sub-commands accept additional arguments that are documented in the reference page for the utility program the sub-command invokes.
In order to handle the problem of not having the text to draw posed the first of many design issues concerning the text object. The object could create its message and broadcast it across the network, so this way the other white board would know the new object does exist. This would not hurt anything, because basically it would draw nothing on the screen. This was not a very good approach since it would cause a lot of network traffic. A message would have to be sent in order to create the new object. Then the client had to find and update the object with the current text to be typed. Now this posed the next question. How would the text object be drawn.
Should the text object be drawn directly on the easel page or be temporarily stored and then sent when the whole message was complete. If the text was drawn directly on the Easel Page, the white board would have to handle a message sent across the network every time a key was pressed. The white board would be required to read the character that was typed in, know which text object the character belonged to as well as find that object in the list of objects on the Easel Page and then send a message across the network Since requiring the capability to draw on the Easel Page would cause a huge amount of time and waste of network band width the option to temporarily store the message and then send the message as a whole was the decided option to take.
The next design question then arose. Who should send out the message to be broadcasted to every one when a new text object was ready to be created? And to whom to send this message. Because of hierarchical conditions there were difficulties on how and what to pass to whom. This problem started with who instanciates what, and how are the required functionality to be passed on. The decision of creating a temporary location for the message to be typed and stored until the message was broadcasted to all other white boards forced this message board to become an object. The message board had to be instanciated by the white board, because this was the general location for creation of objects for the Easel Page. The white board also knows the initial starting location that the message should appear and the color of the message. Also the first part of the message for communication purposes is created in the white board. So this was a logical place to instanciate and initialize the text object (the message board). The text object will them be created by the message board. Therefore the message board is passed the partial message too and will complete the message for board casting. This is the first variation from the other objects. The other objects to be placed on the Easel Page are instanciated by the white board then the message board does not know the white board exists. So the problem lied in how to tell the Easel Page to create and draw and broadcast the new object including the text of the object.
So the solution developed required the partial network message to be passed to the message board so it can be added to until the message was completed. Also the current entire white board was passed to the message board. This was the only way the message board could communicate with the server in order to update all white boards. The entire white board was also passed to the message board, so the message board could communicate with the white board such as to kill the window for the message board, so that frame (window that housed the message board) would disappear. And so the white board of the client that created the message gets it displayed on his own Easel Page. The way communications was set up was the sender never gets a copy of the message that is sent out back. So the sender of the network message must report the change to his own Easel Page personally.
The functionality of the rest of the text object acts just like any of the other object that can be placed on the Easel Page. The object can be cut and moved. The text appears on everyone white board if they join the session late. However, there are two other remaining problems that I had to deal with. The first problem was I was not able to correctly adjust the text font size in the message board when the user select the font list button and selected a different size. For some unexplained reason the current font size did not want to erase the characters from the screen completely. The message with the new font size would over lap the same message with the previous font size. Hopefully this can be changed in future versions.
The second problem was when drawing the text message on the Easel Page the location of the text was actually shifted up from where the text was expected to appear. This is due because text draw would place the coordinates at the top of the text, but when drawing an object on the Easel Page as a string the draw operation would place the coordinates at the bottom of the text. This caused additional problems because the user would try to click on the text object in order to move or cut it and the coordinates for the object would be completely off. This problem was solved, but it was not cleanly solved.
However, due to difficulties with communications between the white board and the Tool Kit, this feature caused problems. As the project proceeded more tools were being added to the Tool Kit and frames (independent window) layout were being implemented. The size of the frames including the number of frames that were need to be displayed started to become difficult windows to manage. After several redesign strategies the color palette was going to be moved inside the Tool Kit. Yet again due to difficulties of seeing the buttons for the colors in the Tool Kit, a list button was created. This solved a number of problems such as easily showing the active color.
| Figure 19 | Figure 20 | |
|---|---|---|
|
This is done by default by the list button class type. When you click on the color button as shown in figure 19 a menu of colors would be display in a pull down menu format as illustrated in figure 20. The background color of the menu tells the user the last active color. This allows the user to identify with the current color status at all times. Keeping mind on the windows 95 platform |
|
| Name of File | Description of File |
|---|---|
| readme.html | Gave a brief over view of the Java applet and explained what the applet could do. |
| howto.html | This HTML file informed the user on how to invoke the Java applet |
| techinfo.html | This HTML file informed the user on some technical issues the user must be aware of in order use this Java applet |
| intro.html | Presented the user with a welcome screen and a menu to go to all the other HTML files |
| names.html | A list of the members that created the Java applet |
| conference.html | The HTML file that actually invoked the Java applet |
Each of these HTML files were nothing fancy. They consisted of a simple text lay out and included a image of the Villanova University seal.
I performed a rigorous testing in three stages. The first stage was at the object level. Even though many of the team members did their own testing of the objects as the implemented them. I tested them on the different platforms. The Second stage was a group level. I made sure all objects for the Tool Kit and Easel Page group worked together as a whole. Since many of the team members were focusing on the objects they were making, I made confirmation that the object interacted correctly. It is understood that all team members required other object to help theirs work, I performed the final testing of all group objects.
The third stage of testing I assisted in was the system testing. I helped create network scenarios that tested the application across the network. I brought up several clients and tested the network communication among clients. It was not until the very end was it possible to run clients remotely from different machines. This kind of testing I was not able thorough test enough and should be investigated further.
Testing became every difficult toward the end. Many team members were continually making changes faster then I could test them. As the deadline approached only system and object testing was done. The other factor that made it difficult to do testing was the continual integration that was occurring. The code could not be thoroughly tested until every one completed their integration. This resulted in doing much of the testing in the late hours of the night, because the code was continually being integrated on daily basis.
Writing the documentation was not to difficult because many of the team members formed many of the source code standards that I had set. Such standard consisted of the format of file names, which was provided by Mark Juliano. Many of the variable names match with their function and purpose. Method names were logically chosen. And code appearance made the code easier to understand.
The challenging part was commenting the code. Many of the team members did not comment the code as they went. Therefore much of the time I spent trying to understand the code they wrote in order to document it. However, once it was understood it was easy to comment other portions of code because the team made a great effort to reuse the code.
Top of Paper |
Previous Page |
Next Page |
Bottom of Paper
Written By Graham L. Mehl
Last Modified on April 23, 1996
© Villanova University
