Please conform to the following format when completing your G.analysis. This part of your project will be graded out of a total of 100 points and pro-rated down to the 10 points (of 44) for the group project.
All Component groups must provide to me by TUESDAY a schedule that shows the expected breakdown of work by teammate and by person-hour. That is, given the schedule for the rest of the term (see syllabus) I want a day-by-day breakdown of the total number of hours that you expect to work during the rest of this semester. Note that it is ok to say on certain days "0" if you are not planning on working on the course project on that day.
This schedule is "credit bearing" and will actually factor into your overall grade. If you have questions about what I am looking for, check out the discussion board on sourceforge.
The following deliverable schedule is relevant for: GUI components and Server Components. For Database and CAPTCHA, see the end of this document.
In A1 you developed use cases for each move. For your component you are to develop use cases that reflect its role as a "boundary" to the rest of the system. That is, you are asked to process an external operation. For server-side components, the external operation is encapsulated as a command. For client-side components, the external operation is encapsulated as a request. If you find there are commands or requests that you believe you need (but have not yet been identified) be sure to post to the sourceforge discussion boards.
Each use case will describe a set of events that are required to process the external operation. Make sure that you aim for completeness in understanding everything that your component is asked to do.
The key to getting everything working is a clear understanding for the whole class about the communication protocol of commands and requests.
If you are a client-side component then you must describe the full set of commands that you are capable of generating to the server (make sure they conform to the command set). Use XML to describe a sample command for each one that you are capable of generating. Then go on to describe (using XML requests that conform to the request set) the requests that you expect to receive in response to the command.
If you are a server-side component then you must describe the full set of commands that you intend to process (make sure they conform to the command set). Use XML to describe a sample command for each one that you are capable of processing. Then go on to describe (using XML requests that conform to the request set) the requests that you expect to generate in response to the command. Note that some of the requests are intended to only go back to the client which requested the command (and you need to identify these as "uni-cast", some requests are intended to go to a reduced set of users (identify these as "limited broadcast"), while some requests are intended to go to all connected users (identify these as "broadcast").
Identify the entity classes that are essential to the implementation of your component. Identify the controller classes that are going to be responsible for responding to the external operations.
Provide UML diagrams for all classes, showing expected methods and attributes.
This project will always have different requirements than the others. However, you will have some things in common, namely the need to develop a clear protocol of command and request communication).
You will need to show clearly the two sides of the communication.
You shall develop use cases that "cut across" client and server. That is, they show the end-to-end communication, and you show what is processed as part of the detailed use cases
Since you are developing both server and client-side entities, you will be responsible for both command and request communication. Show XML examples of both types. Note that you should be interested in this request.
Develop the classes as stated above. You will also need to explain the persistent information that will reside on disk as well as discuss the information that you are going to store within a database. Sketch out the database schema you are to use.
Provide UML diagrams for all classes, showing expected methods and attributes.
Develop the database tables that you intend to host the information. Show the schema that you intend to use.
Report on your defined interfaces IUM_DB, IGM_DB, and IPM_DB.
You are insulated from command and requests, nonetheless you are responding to requests to your API and so you should develop classes as part of your analysis object model to show how you will support the interfaces that you define. It is expected that your classes will manage the database connections, iterators over the values that expose database cursors as part of database queries.
While you are responsible for defining these database interfaces, this means you also acquire the responsibility to let the UM, GM, and PM components know about it.
You guessed it, you are the least defined component in the set, but this means you need to communicate directly with me when you have questions. Don't drop the ball!