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.