Reading & Drawing UML Class Diagrams

You will not be graded on producing a textbook-perfect UML diagram in an interview, but you are expected to communicate relationships between classes clearly and consistently - and that vocabulary comes from UML. Five relationship types cover almost everything you will need: association, aggregation, composition, generalization, and dependency.

• -Association: a general "uses" or "knows about" relationship between two classes - a Teacher and a Student are associated, but neither owns the other.
• -Aggregation ("has-a", weak ownership): a whole contains parts, but the parts can outlive the whole - a Department has Employees, but deleting the Department does not delete the Employees.
• -Composition ("has-a", strong ownership): a whole owns its parts exclusively, and the parts die with the whole - an Order owns its OrderLineItems; delete the Order and the line items go with it.
• -Generalization ("is-a"): inheritance - a DebitCard is a Payment.
• -Dependency ("uses briefly"): one class uses another temporarily, often as a method parameter or local variable, without holding a lasting reference - an OrderProcessor might depend on a TaxCalculator passed into a single method call.

The distinction candidates blur most often is aggregation vs. composition, and the test that actually resolves it is lifecycle ownership: if the part cannot meaningfully exist without the whole, and the whole is responsible for creating and destroying it, that is composition. If the part has an independent lifecycle and could belong to a different whole (or no whole at all), that is aggregation. A Car has an Engine (composition - the engine is built with the car and scrapped with it); a Car has Passengers (aggregation - passengers exist before, during, and after being in this particular car).

The practical whiteboard technique: underline every noun in the requirements (candidate classes), underline every verb (candidate methods), then draw a relationship arrow for each sentence that connects two nouns. "A Library has many Books, and a Member can Borrow a Book" becomes: Library o-- Book (aggregation, books can exist without a specific library record), and a dependency or association line from Member to Book via a Loan class that represents the borrowing relationship itself as a first-class object.