Example Structure Charts (Object Models or Class Diagrams)
for Lab Documentation

Archive: If these gifs do not come up, click on them from this page
• Object Model (Structure Chart) for an ATM machine. This is incomplete (it does not have variables and methods) but it shows nice use of association links.

• Object Model (Structure Chart) for an air transportation system (somewhat more complete - return type and parameter listing needed for methods (i.e., method "signature") and type needed for variables)

  • Note that in this diagram, the links have the association name written on them. At the end of the links, are the specific identifiers of the association. These end up being variables in the classes. For example City is connected to Airport. So the City would probably have an "airport" Instance Variable and the Airport would probably have a "physical location" Instance Variable. You do not need to do this since if they are instance variables, you would have them listed in the Variables section

• Classes that you use but did not write yourself (i.e., you inherited or implemented the interface for) should be shown with a rectangle (with just the name of the class) with the proper links indicating the type of connection to your classes. These do not need to be fully expanded nor do they need ADT information. Also, for inheritance, you only need to show up one level in the hierarchy (i.e, who you explicitly inherited)
• Classes that you wrote should show the name, the variables and the methods. These also need to have ADT information (also, in brief)
• If a class has an instance variable of another class, then this is an association and an association link should be provided

• graphics draw
  Do not give Association links with link names of consists of or has. This holds absolutely zero information content. Of course it "has" the class - the class would not exist at all if the program did not "have" one of them. So, "have" tells me nothing.

  Hence, one should only use Aggregation links (A-Part-Of) when that it the only reason a certain class is there (i.e., because it is a-part-of a bigger class that is needed). In general, links should give some kind of useful information. This example is OK because it uses aggregation for the GUI parts. I.E. the GUI has three containers to it and one of them holds a Button. It would have more useful information though, if the links said something like "figure controller" and "color chooser" since that is what the ToolBox and ColorBox do in the JPaint Applet

  In general, Association links are meant to show the reader why a class was used. For example, perhaps it is the GUI and hence the "view/model" link in a Model/View/Controller architecture. Or, java interfaces connected to GUIs provide "view/controller" links. Always try to give useful information so the reader can look at the Object Model and have a very good idea how/why it all fits together.

• Finally, here is one from the free open-source ArgoUML tool to help you build them.