UML - Containment and Inheritance Diagrams
Containment Diagrams
Containment diagrams are graphical representations of class relationships within a program. Now that you're familiar with the program, let's review the essential elements of containment diagrams that you will be using.

- Class box: All class names are located inside of a box. Concrete classes, or classes that can be instantiated, are written in plain text. Abstract classes are written in italics. To make your text italicized in the class box, surround your text with // (for example, /HelloWorld/ would be italicized).
- Containment arrow: This shows that an instance or instances of this class are contained, or instantiated within, another class. In this case, one instance of Andy is contained in class CS15Lecture (denoted by the unfilled diamond), while several instances of CS15TA and several instances of CS15Student are also contained in class CS15Lecture (denoted by the filled diamond). The diamond acts like an arrow head, pointing from the class to the class that contains it.
- Reference arrow: This means that the class has a reference to, or knows about, the class to which it is pointing. In this case, there is an instance of TabletComputer in class CS15Lecture as well. Andy needs to know about his TabletComputer. Therefore, Andy has a reference to the instance of TabletComputer in CS15Lecture.
Now that we know the lingo, let's try creating one of our own.
Check Point 2
- Find a partner. Together, you will discuss a containment diagram that models an aquarium.
- Your containment diagram should start with the App class (just like the diagram we gave you for LiteBrite). The App class should contain the top-level class for the Aquarium. Your Aquarium will need to include several things: fish (don't use specific types of fish; a general class will do), an aquarist, fish tanks, and visitors. Naturally, the aquarist knows about the fish, since s/he takes care of the fish.
- With your partner, make a diagram that logically shows a program with the above specifications. Think about what makes sense to you. Obviously, the visitors will not be contained inside of the aquarist, so where should the visitors go? Each of you should use UMLet to create your own diagram. This is like CS15's collaboration policy (sort of: in our collab policy, you can't take away any notes from your design discussions, and you cannot draw diagrams together) - talk about design with your partner, but create your own diagram. Note - In programs of greater complexity, there are often multiple designs that are equally valid.
- Make sure you show and explain your diagram to a TA before you continue. Be sure to explain how the association between the aquarist and the fish is made (hint: you only need to show the final association, but you need to know how it would be coded).
Congratulations! You've just completed your first UML diagram!
Inheritance Diagrams
Inheritance diagrams show the relationship between a super class and its subclasses. Inheritance diagrams, or trees, look a lot like family trees, and rightfully so. As you've just learned, a child class inherits the traits of its parent, much like you inherited your eyes and hair from your parents. Unlike you, a Java class can only have one parent.
To demonstrate an inheritance diagram, let's revisit our earlier UML example. As you remember, in CS15Lecture, we had both CS15TAs and CS15Students. Even though these classes are different, they have many similarities, as both are BrownStudents. This inheritance structure would be diagrammed like this. Remember, inheritance diagrams and contaiment diagrams are separate. It is a good idea for your inheritance diagram to resemble the example and work itself down vertically.

- Inheritance Arrow: This means that this class extends or inherits from the class to which the arrow is pointing. Both CS15TA and CS15Student inherit from BrownStudent
- Interface Circle: This means that this interface is implemented by the classes to which it is pointing. Both CS15Students and CS15TAs implement the interface Teachable (after all, CS15 TAs are still learning too!). If you need to diagram an interface, double click the circle and extend the screen (the interface element appears in the very upper left hand corner). You need only provide the interface name. The line from the circle to the class is located next to the stick figure.
It's perfectly fine to connect these two inheritance trees because the fact that they implement the same interface creates a relationship between these classes!
Check Point 3
- Remember the generic Fish class we used in the UML diagram? Well, we don't want just one type of fish; our aquarium has a diverse collection of specimens. Design an inheritance tree that allows for many different fish (note: this diagram should not be connected to your containment diagram in any way).
- Let's dig a little deeper into the aquarium example - do you see two other classes that could be generalized into another class (hint: these two classes could also share a parent class with you and me!)? Draw an inheritance diagram for these classes as well.
- Fish, visitors, and the aquarist all know how to eat. Figure out a way to implement (hint) this and draw it in the inheritance diagram.
- Show a TA your inheritance diagram.
More Complex UML Diagrams
The containment and inheritance relationships between classes can become tricky to display. For example, let's say the super class BrownStudent contains two instances of the Eye class. While CS15Student is a subclass of BrownStudent, we don't want to show CS15Student as containing two Eye instances in the above UML diagram (that is not the true containment relationship!) Instead, we would show this more complex containment relationships as shown below:

We display BrownStudent as containing multiple instances of Eye in the same diagram as the CS15Lecture, but there are no connections between BrownStudent and the CS15Lecture itself. They are related because of the inheritance relationship between CS15Student and BrownStudent. This is important for TASafehouse!
Now you can design and create diagrams with the best of them! Remember to use UMLet for all of your design questions when diagrams are required! Not using UMLet will result in deducted points.
UMLet is available for your personal computer, if you don't feel like schlepping to the SunLab for your diagrams. The download is available from umlet.com (use the stand-alone version). Be aware, in order to run this version of UMLet, you must have the latest version of Java (1.6, also known as SE 6). If you run into problems trying to run UMLet on your own computer and have questions, e-mail the head TAs for help or come to their hours.
Collaboration and Design...
Collaboration and design go together like cake and icing. Like peanut butter and jelly. Like programming and caffeine. There will be times when the program specs seem impossible, or when you have no idea where to start, and talking through the design of a program could be just the kick-start you need!
CS15 allows collaboration on design after the Cartoon project, but only under certain stipulations (see the Collaboration Contract, available on the website, for the conditions for acceptable collaboration). Design allows plenty of opportunity to work together. We encourage you to discuss design with your classmates or with us! Just remember to not take notes away from your discussion (use a whiteboard and erase it!) and to let us know who you discussed your design with in your header comments.
Remember to get checked off by a TA for this lab!