Term Project - Milestone I
CS211 Fall 2000 Accelerated Stream

UML Class Diagrams

Due Thursday, October 26
(at start of 10:10am class)

The first project milestone is a design document consisting of a small number of UML class diagrams. The purpose of this set of diagrams is threefold:

(1) to show all of the non-gui classes and interfaces that you plan to define,
(2) to show the essential members of each of these classes and interfaces, and
(3) to show how these classes and interfaces fit together to form a coherent whole.
A typical implementation of the traffic simulation will have perhaps a dozen or so classes and interfaces (that number may vary considerably, depending on the approach that is taken).

To get started, you might find it useful to pick out one of the components of the system that's mentioned in the "General Framework for Simulation" and think about (a) what its essential aspects are and (b) how it relates to the rest of the system. For example, consider the abstract class Agent... What subclasses might it have? [A subclass for vehicles, perhaps? One for traffic lights, as well?] What classes and interfaces might Agent refer to? [One of the supplemental pages mentions that an agent will probably hold a reference to the node (in the map graph) that it's currently sitting on; that's an example of an association between the class Agent and the class / interface for map nodes.] What are the essential operations that all agents support? [The "take one step" method seems like a good candidate for inclusion in the Agent class.] After you've finished with Agent, you might move on to one of the classes that's related to it---one of its subclasses or perhaps one of the classes / interfaces that it's associated with.

Details

Show every non-gui class and interface that you intend to include in your implementation, using the UML annotations for interfaces and abstract classes where appropriate. For each class and interface, show its essential attributes (a.k.a. "fields") and operations (a.k.a. "methods") as well as the primary associations that it has with the other classes and interfaces (and with itself). Also, show all of the "extends" and "implements" relationships that exist. Choose descriptive names for the attributes and operations, and, when the name itself is not sufficient to explain a member, provide a short supplemental comment.

In general, your diagrams will not be as heavily annotated as the UML examples that were given in the September 7 lecture notes. In particular, you do not need to annotate roles, visibility, navigability, or multiplicity. [If you're not familiar with those terms, then please feel free to ignore the preceding sentence.] Also, you do not need to provide signatures or return types for the operations at this time - though you may do so if you wish.

What to hand in

Hardcopy of your UML diagram(s) will be due at the beginning of lecture on Thursday, October 26; we will not be using CUCOON for this milestone. Hand-drawn diagrams are acceptable, as long as they're quite legible, but please be aware of the fact that we'll be making notes on the submitted hardcopy as we grade. Consequently, you might want to submit a (legible) photocopy of your original, since future milestones will require you to submit updated versions of these diagrams.
Also, you will need to submit a copy as part of a Final Design Document (this will not be a large or extensive document) with your finished program and demo of it.

Miscellaneous notes

The first milestone will count towards your final project grade but will be weighted relatively lightly and graded leniently, so long as it is clear that you put a sufficient amount of careful thought into it.  Also, we will be evaluating your design, not your mastery / knowledge of UML, so please don't worry too much about the gory details of the notation.