Projects - CEG-4188 - Fall 2010

General informations

For each project, there should be two teams working on its realization. Note: this year, there is only one team

For each project, there are the following phases of work:

1. Analysis of the problem and definition of the communication protocol between the different system components (jointly done by the two teams)
2. Implementation and test of the system (separately by the two teams)
3. Verification of the campatibility of the two systems developed by the two teams (done in collaboration)

Schedule

• November 10: choice of project
• December 8: Demonstration of the system to the prof
• December 15: Deadline for the written report

Content and format of the report

The report should contain the following sections:

• Introduction: 1 to 3 pages explaining the purpose of the project, the objectives aimed, possible applications in the real world, and some comments about what you have learned from doing this project
• Problem analysis: Present a conceptual model of the system and its environment (maybe using UML diagrams) showing the different user roles, the components of the system, and required resources and data; explain the problem to be solved and define the requirements of the system to be built. Analyse also the possible architectural structures and consider the possible use of existing protocols in the context of this project (e.g. IP, TCP, RTP, HTTP, SMTP, FTP, JPEG, or XML, for instance). Identify the possible conceptual choices (including protocols to be adopted) and discuss their relative merits.
• Definition of the communication protocol: Define the communication protocol that you have adopted for this project.
• Implementation design: Explain your approach to implementation, the software architecture, any implementation choices, choice of programming language, choice of implementation platform, any deployment constraints. You may include some code sections for your explanations. The complete listing of your program should be in the annex.
• Tests: Explain the tests that were performed to verify that the system requirements were met. Explain why these tests were selected. Note the type of errors that were found during the debugging process.
• Observations: You may show some user interface images, discuss the subjective user experience with the application. You may also discuss problems encountered during the development of this project. A critical analysis of the obtained results is welcome, for instance, comments about the range of tests that were performed, or security problems that were identified in relation with the protocols adopted or in relation with the adopted implementation strategy.
• Conclusions: Elaborate on: (1) Where the objectives atteint? (2) What did we learn from this project? (3) What were the sources of errors, bugs, problems? - or any other remarks.

Note: The user interface is not so important and may remain simple - as long as a demonstration of all the possibilities of the implemented system can be given.

List of possible projects:

• Tic-Tac-Toe: This application allows two persons to play Tic-Tac-Toe. Each user is identified by an alias chosen by the user. A user that wants to start a game with another user has to enter the DNS name of the computer of the other user. The latter can accept or refuse the game proposal. If accepted, the two users play the game. The application program must avoid illegal moves. When the game finishes, the result (win, loose, equal) must be shown to the user and an invitation to start another game should be offered. When one of the users refuses the proposal, the application should show the number of times the use has won (over the total number of games played during the session). - Note: You may consider the question how one can select randomly which party will be allowed to to the first move.

• Tic-Tac-Toe with arbiter: This project proposes a different architecture for the game: Here the two user agent programs do not communicate directly with one another, but insted they both communicate with a server that keeps track of the state of the game. It is proposed that the user agent program does not verify the validity of the moves, but this is done by the server program, which is therefore also called the arbiter. The arbiter determines who wins and sends error messages when an invalid move is made.

  • Optional: Generalization for an arbiter infrastructure that can be used for different games where the users share a board with tokens placed on the board. The protocol between the user agent programs and the arbiter should be general enough so that it could be used for different games, not only Tic-Tac-Toe, but also, for instance, chess. The server program would contain an arbiter sub-program that is specific to the particular game and would verify the validity of moves and the winning condition.