A class designates common structure, common behavior, and common relationships for the objects of that class. Classes are represented in the UML as a rectangle with three compartments for the name, attributes (data), and operations (functions/methods). For your lab, you need only show the name in the class diagram.
Class Diagrams show you the static nature of your system. These diagrams show the existence of classes and their relationships in the logical view of a system. In a larger system, you will have many class diagrams.
There are many free tools to draw simple UML diagrams; any tool will be fine. (Don't do ascii diagrams like the ones here; it's just simpler in a document like this.)
The UML modeling elements found in class diagrams include
-- Classes and their structure and behavior
-- Association, aggregation, dependency, and inheritance relationships
-- Multiplicity and navigation indicators
Relationships represent a communication path between objects. There are many types of UML relationships including association, aggregation, and inheritance. Another important relationship is dependency which is a more subtle form of association. While some of your relationships may actually be dependence, for this lab, don't worry about showing that. In lab5, you will only show composition.
Association is a bi-directional connection between classes. An association says I can send you a message because if I'm associated with you; I know you exist. This is represented in the UML as a line connecting the related classes, typically with a phrase on the line describing the association.
+----------+ +----------+
| Student | buys | Book |
| |------------| |
+----------+ +----------+
Aggregation is a stronger form where the relationship is between a whole and its parts. An aggregation tells my developer that there is a strong coupling between those object classes. This is also known more specifically as composition and is represented in the UML as a line connecting the related classes with a diamond next to the class representing the whole. (For this course, don't worry about an open or a solid diamond. You'll care in CSS 370.)
Multiplicity defines how many objects participate in a relationship. It is the number of instances of one class related to one instance of the other class. For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship. Multiplicity is represented as a number and a * is used to represent a multiplicity of many.
+----------+ +----------+
| | 1 1| |
| Student |<>--------| Address | Explanation -- One Student object
| | | | has one Address object
+----------+ +----------+
+----------+ +----------+
| | 1 *| |
| CardDeck |<>--------| Card | Explanation -- One CardDeck object
| | | | is made of many Card objects
+----------+ +----------+
It sounds silly, but people refer to this kind of relationship as "has-a" . A Student object "has-a" Address object. A CardDeck object "has-a" (many) Card object.
Inheritance is briefly described here although you will not use it in lab5. That is not to say that it isn't useful in lab5, but solve it without using inheritance (which is covered in CSS 343). Inheritance has enough differences in C++ that it takes some time to learn.
Inheritance is the relationship between a parent and child class (terminology meaning the same thing is superclass and subclass, or base and derived class). A child class inherits (acquires) all members from the parent class and typically has more members allowing additional behavior. This is represented in UML with an arrow where the arrowhead is an open triangle.
+------------+
| Person |
+------------+
/_\
|
|
+--------------+
| Student |
+--------------+
/_\ /_\
| |
| |
+-----------+ +---------+
| Undergrad | | Grad |
+-----------+ +---------+
Inheritance is "is-a" relationship. An Undergrad object "is-a" Student object. A Student object "is-a" Person object.