Class Diagram

Association. A plain line. It means the two classes know about each other.

Add an arrowhead to make it one directional. Then only the class at the tail knows about the one at the head. In the picture above, Flight points at Aircraft, and the aircraft knows nothing about the flight.

Multiplicity. Numbers written at the ends of a line, saying how many instances take part. 1, * for many, 0..1 for optional, 2..4 for a range. In the picture, a FlightInstance has exactly two Pilots, and a pilot has many flight instances.

Aggregation. A hollow diamond at the whole end. The part can outlive the whole. An Airline aggregates Aircraft: shut the airline down and the aircraft still exist.

Composition. A filled diamond at the whole end. The part cannot outlive the whole. A Flight composes its WeeklySchedule: delete the flight and the schedule is meaningless.

Generalization. A solid line with a hollow triangle pointing at the parent. This is inheritance. Crew, Pilot and Admin are all a Person.

Realization. A dashed line with a hollow triangle pointing at the interface. An interface is a list of operations with no code behind them, and realization means implementing one. It looks like generalization on purpose, because it is the same idea with no code inherited.

Dependency. A dashed line with an open arrowhead. One class uses another without holding it, usually as a parameter or a return type. FlightReservation depends on Payment.

Those seven are the whole vocabulary. Here they are together, which is the same legend that sits inside every case study in this course.

The one test that decides most lines

Aggregation and composition look almost the same. Most candidates choose between them almost at random. There is a one sentence test.

Destroy the whole. Does the part still make sense on its own?

If yes, it is aggregation, a hollow diamond. A library that closes does not delete its members; a person exists either way.

If no, it is composition, a filled diamond. A parking lot that is demolished takes its floors with it; a floor of a lot that does not exist is nothing.

Say the test out loud when you draw the diamond. The interviewer then hears a decision instead of a guess.

How much detail to draw

A whiteboard is not a code generator. Aim for this:

• Every class gets a box and a name. Ten to fifteen boxes is a full answer.
• Attributes only where they matter. The two or three fields that carry the design, not every string.
• Operations only where they are interesting. The methods that appear in your flows.
• Every line gets a relationship type and a multiplicity. This is the part not to skip. An unlabelled line is a decision you have not made.

If you run short of time, drop attributes before you drop relationships. A diagram of named boxes with correct lines is a design. A diagram of fully specified boxes with vague lines is not.

Key Takeaways

• The class diagram shows what classes exist and how they connect. It is the only UML diagram that maps directly onto code.
• A class box has three parts, - marks private and + marks public, and an abstract class is written in italics.
• Association is knowing about, aggregation is holding, composition is owning, generalization is inheriting, realization is implementing, dependency is using.
• To choose between aggregation and composition, destroy the whole and ask whether the part still makes sense.
• Draw every box, but only the attributes and operations that matter. Never leave a line without a type and a multiplicity.

The class diagram says what the design is. It says nothing about what happens in what order. The next lesson covers the diagram that does: the activity diagram, which walks one flow from start to finish.