Class and Sequence Diagrams First, the UML doesn't talk about class diagrams anymore, it refers to structure diagrams and then just tells you what icons are appropriate. In industry, however, "class diagram" is a phrase with meaning, and "structure diagram" does not necessarily mean what the UML committee says it does. Soooo, for the purposes of this class, call them anything you want, but be sure to have the all the information we ask for in them somewhere. I've named my "class/structure/whatever" diagram types - you can use my names or make up your own. A class is represented in the UML like this (And this is for sure - your classes MUST be represented this way - no wriggle room at all): ClassName Attributes attribute1: data_type = default value attribute1: data_type = default value attribute1: data_type = default value . . . Methods method1(argument_list): return_type method2(argum.ent_list): return_type . . . If you want to, you can identify private attributes by preceding them with a "-" and public ones by preceding them with a "+", although it's not necessary for cmps 115. Class Diagrams Once you have all your classes described, you have to develop a static view of how they fit together. Usually one view is not enough to show all the relationships - it gets too complicated if you try to cram it all on one drawing, and a simple drawing doesn't get all the necessary relationships. The static views, when taken in combination, should show all the classes that your game is going to use (although not all classes have to appear on all diagrams) and their relationships to the other classes. If a class doesn't seem to belong on one of the class diagrams you have to draw, you should wonder if the class is necessary. I've elected to do four drawings. In order A conceptual association diagram - it shows what objects I'm going to use and how they interact, but not anything about what instances of the objects will be created. An implementation association diagram - it shows the instances of the objects I'm going to use. Instead of just saying "JButton", I show how the "RestartButton" interacts to accomplish various tasks. This is probably the most interesting of the drawings - it shows what relationships DON'T exist, as well as those that do. For example, it shows that the Gameboard doesn't know anything about Help. An inheritance diagram - it shows what objects have parents and children, so you can see what capabilities are inherited A true structure diagram - similar to an ER diagram in databases, shows multiplicity of relationships. Sequence Diagrams: Sequence diagrams are drawings that show dynamic relationships. For each use case, you identify the classes that have to participate and put them across the top of your drawing, plus the actor at the far left. The actor then starts the sequence with some action that you have documented previously and, finally, you show the hand-off from method to method to get the job done. The drawing shows the class that contains each method used, and the arrow heads are at the end of the arrow that points at the class that holds the method, not the class that invokes the method. You can show internal methods being called by drawing a looped back arrow, and you can write notes to identify potential alternate paths that are too trivial to make standalone drawings for.