UML Designs for a Collaborative Virtual Environment

Part 1: Requirements Analysis

The requirements for a collaborative virtual environment application are complicated. Kind of like obscenity, we know one when we see one, but this document will tackle the hard problem of making it explicit.

1.1 Requirements Specification

The CVE will consist initially of two primary components, a client and a server, which operate extensively together. While the requirements emphasize overall user functionality in contrast with design documents that capture details that are specific to client or server, it is pretty tempting to do a separate requirements analysis for the client, and for the server, each treating the other as an external actor.
1.1.1 Requirements for the Client
The CVE client will provide a 3D view of a virtual world.
Initially, this will consist of a simplified approximation of NMSU Science Hall 1st Floor.
The CVE client will enable users to see each other
Representation of users will consist of a simplified approximation of a humanoid form called an avatar. Avatars will usually include elements of the user's actual appearance. Seeing each other implies seeing gestures such as pointing, and being able to see who is talking.
The CVE client will enable users to communicate with each other
This includes text chat and voice chat.
The CVE client will enable users to collaborate on computer science subject matter.
"Collaborative" means not just seeing each other, but seeing what each other are doing, well enough to coordinate. This includes collaborative drawing on whiteboard/chalkboard, and collaborative editing of files of various types (code, UML diagrams, documents).
Nonfunctional requirements
The client rendering of the 3D model must run "fast enough"
It must achieve 24-30 frames per second on current midrange hardware.
The CVE must be "reliable"
Disconnects must be infrequent; work should not get lost.
1.1.2 Requirements for the Server
The server must authenticate users
The server must provide secure communications
Mainly, because the server must authenticate users
The server must handle class-scale numbers of users
The server must maintain the dynamic state about the virtual world
In particular, it must copy that state out to clients, and allow updates
The server must support persistent state, e.g. across reboots
These requirements are not remotely complete; what would you add?

1.2 Client Use Cases

Client's Actors - student, instructor, admin, guest, server

Use Cases - login, move, open/shut door, draw on board, chat, edit file, read file, make program, run program, debug program, attend class, attend lab, take test, take quiz, ask question,

1.2.1 Client Use Case Diagram
1.2.2 Client Use Case Descriptions
Open File

Summary: A user performs this task in order to view a document. The user specifies a filename and the document is opened in a new window.

Steps:

  1. Choose "Open" from the menu bar.
  2. System displays a File Open dialog.
  3. User selects a filename and clicks "OK".
  4. System closes the dialog and opens the file in a new window.

Alternative: If the user clicks Cancel in step 3, no file is opened.

1.3 Server Use Cases

Server's Actors - client, admin, repository?

Use Cases - create account, serve connection, ...

1.3.1 Server Use Case Diagram
1.3.2 Server Use Case Descriptions

Invisible Avatars

We don't want to render the user's avatar at all when in the avatar's-eye-view mode. I think we want to insert/remove the user's avatar from the display list pretty much on the fly whenever switching between that view mode and the others. \delavatar was a non-trivial which I may or may not have preserved correctly in the current CVS code, but I imagine we want to add methods to institutionalize its graphical effect and actually remember the display list elements it removed so we can reinsert them very quickly without re-calling render(). I think this means a "visible" flag in the avatar class and a couple supporting methods to make an avatar vanish or show up again.