CS340, lab plan

Lab 5: Feb. 25/27
In-lab Activities

Goals for this week (before next lab);

A. Requirements documentation:

Complete SRS for your client (on Weds.)
Plan to swap documents with your partner group this week, and plan to review partner group's SRS document before the next lab.

Eventually your group will design and implement the client described by their SRS. They are your "customer" and they will evaluate your final work-product.
Before next lab, your group will review their SRS to identify questions or problems.
You should prepare a list of problems or issues that you provide your partner group by Weds., March 12, at 3:30 pm.
You can meet with representatives from their group and negotiate or resolve any problems.
They will modify their SRS by Friday, March 14.

In the next studio-lab, you will need to present some problems and issues in your partner group's SRS. The revised SRS will not be due until Friday, March 14.

B. Server Requirements:

In Lab 5 this week, pairs of groups will discuss what they think is required for the server. We will not require you to write formal SRS, but you will create documentation about parts of the requirements for the server. This documentation will include:

A data model of what the server stores or maintains for the virtual world and all that is in it.
What communications are needed between both clients and the server.
Any states that the server may be in. (State modeling will be taught later.)

What you write up will be submitted before Lab 7 (March 17/19).

In discussing data models, focus on data or information defined at the requirements level (the problem space) and do not introduce design level data at this time. You could document data using text (bullet-lists etc.) or using UML class diagrams.

In discussing communications requirements, again you should describe what's needed as requirements (not design). These are system requirements not end-user requirements, but again focus on "what" not "how". Examples:

Server notifies client that a specific character wants to initiate chat with client's character.

NOT: server sends string "chat initiate Bob", or sends some specified XML, or sends 0xFE followed by an int that's the size of the string to follow....

Client requests to be sent a list of room descriptions for all rooms in server's world.

Pay attention to:

confirmation of messages sent and received.
responses to messages (confirmation, data, result, etc.)
dealing with errors or missing or unexpected responses.

Eventually you must document a complete communications protocol that include an interaction that supports all requirements of both clients. Again, this Server Requirements Document must be completed before Lab 7 (March 17/19). Experience tells us that this document will change over time as you build the system.

C. Client/Server Prototyping:

You may recognize that creating an effective client/server combination is a high-level risk for your pair of groups. This is a good opportunity for technical prototyping: you will explore a new technology to learn and demonstrate what is needed before you try to build with that technology.

In lab today, you can start to plan a client/server prototype. First, think about your goals: what technology do we want to try to demonstrate or learn or try out? Make some simple statements about a sequence of steps or sub-tasks to meet this need.

Before the next lab, part of your team should follow these steps or tasks to attempt to reduce the risks and increase your knowledge of client/server programming.

In the next studio-lab, your group will present the goals of your prototype, what progress you've made, and what problems you've encountered and what solutions you've found (if any). Then you will submit a short prototyping report (a simple write-up) and your source code before Lab 7 (March 17/19).

For submission just before Lab 6 (March 10/12):

Draft of communications requirements document. (For Weds. lab only.)

For presentation in Lab 6 (March 10/12):

Report on requirements issues, problems, experience.
Overview of client/server communcations

Groups or categories of messages. General strategies (e.g. confirmation, responses)

Some client/server communications protocol requirements examples (two or three slides)
Use-cases: For two important client functions, document a use-case to show how the client and server interact to achieve this. (Do ones that are useful for you.
A report on what you've done and learned from your prototype experience

For submission later that week:

Comments on SRS to partner group by Weds., March 12, at 3:30 pm.
Revised SRS by Friday, March 14 at 5pm.

For submission just before Lab 7 (March 17/19):

Prototype report, sample code and executables
Server requirements document, including communications protocol requirements and data model.

For presentation in Lab 7 (March 17/19):

Initial design descriptions for client and server
Preliminary protocol design (messages, encoding)

[Information from this point on subject to change.]

For submission just before Lab 8 (March 24/26):

something

For presentation in Lab 8 (March 24/26):

Communications protocol design document.

For submission just before Lab 9 (March 31/April 2):

For presentation in Lab 9 (March 31/April 2):

For submission just before Lab 7 (March 17/19):

For presentation in Lab 7 (March 17/19):

Work-products in final portfolio:

Group Process Document (on-going modification)
Software Requirements Specification document for one client (due Feb. 28)
Requirements modification report (due March 10/12)
Client requirements list (spreadsheet) (due March 10/12)
Server requirements document (due March 17/19)
Communications Protocol Document (both requirements and design)
Server Requirements Document (not IEEE 830 style)
Client Design Document
Server Design Document

Lab 5: Feb. 25/27 In-lab Activities

Lab 5: Feb. 25/27
In-lab Activities