CS329 Software Engineering II
Linux-P2P-Wifi-AudioFileSharing
Project Musings and Synopsis Document
Linux-p2p-wifi-audio-file-sharing project
Professor: Dr. Ralph Johnson
TA: Danny Dig
Spring 2003
Group Members:
Kabe VanderBaan
Vivek Thakkar
Isaac Sanchez
David Bowen
Michael Walsh
Faisal Sal Razzaq
Ryan Gordon
Srinivasa (Srini) Kattragadda
http://linux-p2p-wifi.sourceforge.net/
Introduction
The point of this document is to address the following items:
a) What happened this semester in the linux-p2p-wifi-audio-file-sharing project?
b) How did we follow RUP?
c) What unique challenges did we face as a group and how did we handle this?
The initial idea for the project is to build an open source, peer-to-peer audio file sharing system using the wifi (802.11b) standard and Linux. However, as the project evolved, it became evident that it could run not only on Linux and over 802.11b, but on any platform with the appropriate Java Virtual Machine, and any network connection using the Internet Protocol (IP). Therefore, for ease in development, the application is known to run on Windows based machines.
Put simply, peer-to-peer computing is the sharing of computer resources and services by direct exchange between systems. Peer-to-peer computing takes advantage of existing desktop computing power and networking connectivity, allowing economical clients to leverage their collective power to benefit the peer-to-peer community. In a peer-to-peer architecture, computers that have traditionally been used solely as clients communicate directly among themselves and can act as both clients and servers, assuming whatever role is required by the application.
This project uses the p2p architecture for developing an audio file sharing system. However, we've made an effort to make it independent of the underlying platform. Further references to p2p and systems developed with a p2p architecture can be obtained at the following URL: http://www.openp2p.com/.
For this project, we decided to use the JXTA (http://www.jxta.org) p2p protocols. The implement of JXTA we chose is an open-source Java implementation. This acts as our middleware to locate other peers available on the network (e.g., the Internet). The application we've used to derive the protocol code is instantp2p.
To follow this course, we had to choose between RUP and XP as our software development process. Last semester, we eventually decided to use RUP since we are distributed and XP is traditionally not a process designed for a distributed group. Likewise, we have followed RUP throughout this semester.
Please check the following link for roles in the group:
http://linux-p2p-wifi.sourceforge.net/roles.html
RUP places a lot of importance in the project documentation and upfront design and planning. A lot of the design and documentation was accomplished during the first semester. But this semester saw a lot of code developed and the use cases were implemented. Below are the use cases that were implemented, and the documentation that was created.
Use-case Auto-detect/Peer Discovery:
- Implemented
- Tested
- Reviewed
Implemented Use-case Search
- Implemented
- Tested
- Reviewed
Implemented Download
- Implemented
- Tested
- Partially Reviewed
Implemented Upload
- Implemented
- Tested
- Partially Reviewed
Implemented Pause Download
- Implemented
Implemented Cancel Download
- Implemented
Project Documentation
As part of the RUP project documentation, we have developed the following artifacts:
1) Project Plan (3 Iterations)
2) Requirements Document (3 Iterations)
3) Use-cases (2 Iterations)
4) Architecture Document ( 3 Iterations)
5) Class diagrams ( 3 Iterations)
6) Test Plan ( 2 Iterations)
7) CM Plan (1 Iteration)
Along with this, the project page holds all the meeting agendas, transcripts, and summary. http://linux-p2p-wifi.sourceforge.net/
We’ll start with the conclusions on whether or not we followed RUP.
Develop Software Iteratively – Yes
Iterative and incremental software development process is one of the best practices preached by RUP. For every iteration we were required to do planning, requirements, analysis and design, implementation, testing, and evaluation. For the current semester, we've gone through three iterations and for each iteration we've developed a project plan, requirements spec, architecture document, class diagrams, test document, code, and finally performed a review on the artifacts for the undertaken iteration. The individual artifacts for each iteration are ample proof of our following an iterative approach. At the same time, for every new iteration, we've developed our system a little bit more thereby following an incremental approach as well.
Managing Requirements -- Yes
Managing requirements is absolutely vital to any project and RUP does include this as one of its best practices. At the start of every single iteration that we have performed, we've identified any changes to our requirements and updated the requirements specification. At the same time, all major functional requirements that we've captured through use-cases have also undergone two iterations. This has helped us further track any decisions that we might have taken with respect to system requirements. The requirements spec. has undergone three iterations while the use-case details have undergone two.
Component-based s/w architecture – Yes
RUP emphasizes on architecting and designing the system upfront. It encourages the architecture to be based on components so as to maximize reuse, enable better cohesion, minimize coupling, and make the architecture as resilient as possible. For our project, we've used an OO language such as Java as our implementation language. This has helped us design our system in term of objects thereby maximizing the cohesion and minimizing coupling. At the same time, we've designed our system at a very high-level in terms of three layers. The three layers form the three major components in the system providing our system with three levels of abstraction. The architecture document has undergone three iterations and it clearly describes our layer/component based architecture in further details.
Visually Model Software – Yes
For the project, we've modelled our design using Unified Modelling Notation(UML) using a number of tools ranging from Visio 2000, Agro UML, & Visual Paradigm. Modelling with UML has allowed us to comprehend our system in its entirety. It has helped us to visualize, construct, and understand the behaviour of the individual components and the interaction of the various individual classes within each component. Modelling our system using UML has further helped us communicate the design decisions and details to the various members of our distributed team spread across three time-zone within the country. The class diagrams have also undergone three iterations and depict how we've modelled our system using UML. Some of the inconsistencies, dependencies and inflexibilities of the design identified through using a UML notation such as this have also been fixed in the next iteration.
Continuously Verify Software Quality – Yes
The following has allowed us to verify our software quality at every iteration and within iterations
1) Writing system test cases based on scenarios for each iterations
2) Performing reviews of artifacts by using pass around review technique whereby the artifacts is passed to all the team members who in turn review the artifact individually and send their feedback to the author of the document. Upon the changes made after the review, this updated artifact is again passed around the team for final verification validation.
3) Although we are a distributed group, four of our developers are in the Chicago area. They have been able to get together in person from time to time which has led to better communication, code reviews in person and has contributed immensely in helping us develop a higher quality of code.
Control Changes to Software – Yes
We've recognized the need to use a Software Configuration Management tool right from the beginning of the project even when we were an XP group before being asked to convert to RUP. We decided to host our project on source forge and use CVS on source forge for setting up our repository for all project artifacts. Currently, we are using an alternate configuration management method instead of CVS on source forge for lack of resources mainly time on the part of our team members to set up the CVS on source forge. The CM plan identifies this alternate strategy in its document.
At the same time, we recognize the need to have a CCB(change control board) as identified by RUP for controlling any changes to the artifacts after they've been baselined. We've already set up a CCB to approve/reject such change requests and have identified a detailed baselining and change request workflow as part of the CM document.
Refactor code – Yes
We initially concentrated on making the code work. Being new candidates to JXTA technology, we spent lot of time and effort just to get one peer-to-peer connection working. After we figured out few intricacies of JXTA and able to get the file transfer working, we spent time to refactor the code and make it efficient.
a.) We undertook a very interesting but highly demanding project in terms of the
technology used, learning curve associated with it, and the time demands on each
team member. None of us have had previous p2p experience, nor have anyone of us
any idea of any existing p2p protocols. During the inception and elaboration phase, we
distributed the team in to small groups and assigned pairs to look at a particular p2p
application that implements a particular protocol using a particular language. The idea
was to get the entire team get familiar with existing p2p implementations and pick a
reference p2p application that everyone should try to understand and along with it
pick a p2p protocol. The initial bend was towards gnutella, however, it became clear
with time that using jxta p2p protocols was a better option. Not only is the protocol
very well specified, there are plenty of open source implementation available that can
be looked at. Another reason for going with jxta was that unlike most open-source
projects, jxta implementations were very well documented making it that much easier
to understand them. However, JXTA as a protocol itself is very extensive and would
take a very long time for any individual to understand just its specification let alone
the implementation. For this reason and the simple reason that the idea is not to
reinvent but reuse, we decided to use the core protocol layer implementation of jxta
from one of the existing implementation in Java called instantp2p.
b.) Another significant challenge was losing half of our group from last semester. Because we used a less known technology like JXTA getting everyone up to speed quickly was a challenge. Luckily all of our new group members were extremely committed and talented programmers so they were able to contribute throughout the semester.
c) Just the requirement of the application to need a peer that downloads and a peer that uploads simultaneously increased the complexity. It needed lot of co-ordination to test the modules that participated in download an upload process.
There were a number of issues that repeatedly cropped up during the course of the semester that are worth mentioning.
A SourceForge (SF) project page has been created and set up for access for members of the group. We have used SF as our CVS repository for documentation and source code for the entire semester. Likewise, we have used SF as our bug tracking tool, and have used the mailing lists to announce bugs and releases. SF was useful for management, but it also introduced issues. Since we did not have complete control of the repository, we had to follow their instructions exactly in order to use the repository. Sometimes this led to delays in updating code because of the process that SF created.
The system is intended to be platform independent and is currently developed and tested on Windows platform. Therefore Java was chosen as the development language. Some of the problems we ran into were using different versions of the JVM. This was easily solved once it was diagnosed since we made sure all developers were using the same JVM.
JXTA was a MAJOR obstacle this semester. Not only was not much was known about the platform, but there was a major release during the semester. The release made some major overhauls of the existing JXTA libs and especially against the apis. A large amount of time was spent reverse engineering the JXTA source code in order to understand how to use the technology in our software. Therefore, as the code was being updated, we had to compile against both sets of libraries, and the compilation had to be in a specific order. This led to major delays in the search functionality of the code. This was the most important part of the project and forced delays in other parts of the code.
The surprising discovery we made is that informal methods such as team meetings over a chat session takes more time and effort for distributed groups than one might think.
·Group Meeting Issues
“A problem occurs any time an individual proposes a course of action in a meeting. What does silence from other group members mean? Implicit agreement? Disagreement? Apathy? Have they left the meeting without telling anyone? (There is no body language to aid in interpreting the silence.) One obvious solution is to ask each individual group member to respond in agreement or disagreement. (We adopted this early on as ‘All in favor, say Yes/No or Agree/Disagree.’) But this solution tended to extremely long and tedious meetings.”
“It is very difficult to gauge your teammate. Normally you'd be in the office and talk with someone. Take them out for coffee and learn about their experience. Doing this over the phone doesn't work. You can't know the strengths and weaknesses of your teammates.”
“It is hard to explain why you're frustrated over the phone. You can't gauge how your partner is going to react, or if he or she is annoyed.”
“Text chat does not really work for technical discussion. Technical discussion needs elaboration, not terseness. Nobody wants to type a lot in a technical discussion, nor to wait for others to type a lot. And, the abbreviations are annoying. You never are sure what they mean.”
·Managing Interruptions
“The whole communication process seems to get destroyed when you get interrupted (i.e. using the bathroom). Laying down a phone just feels different than taking a walk in an office. You feel guilty, like someone is constantly waiting for you. And even if you have a cordless, taking it into the bathroom definitely violates some protocol.”
“Your spouse or your roommate thinks you're not really doing anything 'up there by yourself' and tends to interrupt. This wouldn't happen if your spouse knew someone else was physically in the house. Out in public, people would tend not to interrupt when two people are sitting together and obviously working. But, in our situation, the developer seems to be alone – nobody can really see that you are working with someone else.”
·Lessons Learned
Towards the end of the semester we took advantage of having 4 members of the group within driving distances to get together for the integration aspects of the coding which provided for a wealth of information that was exchanged. It was very easy to see that the team was able to accomplish a lot more in a short period of time when everyone was present in the room and we had audio conferences in all the others. It makes a very significant difference when people are physically present in being able to work and gel much easier and accomplish tasks much more quickly without any need for speculation.
We understood that one of the goals of this project was not merely to produce a software product, but to think and learn about the software process. To that end, we have been intentionally introspective and written a fair amount about problems we encountered along the way.
The team was committed to seeing the project succeed (attendance to the weekly meetings was close to 100%. Our team gelled very well, and experienced a high degree of synergy. The team had smart people who worked extremely hard to get the work done. As is typical of many good software projects, we initially were slow to add new features to the project. But as the time progressed and the end of semester is closing in, we increased our focus on deadlines and met more than once in a week to get things accomplished. Finally, we were able to add most of the functionality to project as we planned at the start of this semester.
All meeting minutes have been posted at: