UML — Class Diagram Notation for OOP

UML — Unified Modeling Language (Class Diagram Notation)

Why this page exists: Association, Aggregation, Composition, and Inheritance (covered in code on "6. Classes Advanced") are concepts. UML is the standard visual notation CS textbooks and CSS papers use to draw those same concepts. This page is the notation key — read it side-by-side with Chapter 6's "Object Relationships" section.

1. What is UML?

• UML (Unified Modeling Language) — a standardized, general-purpose visual modeling language for specifying, visualizing, constructing, and documenting the artifacts of a software system.
• Created by Grady Booch, Ivar Jacobson, and James Rumbaugh (the "Three Amigos") at Rational Software in the mid-1990s; now maintained by the OMG (Object Management Group).
• Not a programming language and not a method/process — it is a notation (a diagramming vocabulary) that is process-independent.
• Purpose in OOP: lets a designer sketch classes, objects, and their relationships before writing code — a blueprint.

1.1 Types of UML Diagrams (classification)

• Structural diagrams — show the static structure of a system:
  • Class diagram ← most important for CSS OOP paper (this page's focus)
  • Object diagram
  • Component diagram
  • Deployment diagram
  • Package diagram
• Behavioral diagrams — show the dynamic/runtime behavior:
  • Use Case diagram
  • Sequence diagram
  • Activity diagram
  • State (Statechart) diagram
  • Collaboration/Communication diagram

MCQ Trap: UML has two main categories of diagrams — Structural and Behavioral — not one. Class diagrams are structural; Sequence and Activity diagrams are behavioral.

2. The Class Box — Three-Compartment Notation

A class in UML is drawn as a rectangle divided into three horizontal compartments:

┌─────────────────────────────┐
│           Student            │   ← Class name
├─────────────────────────────┤
│ - rollNo : int               │   ← Attributes
│ - name : string               │
│ # marks : float               │
├─────────────────────────────┤
│ + getMarks() : float          │   ← Operations
│ + setName(n : string) : void  │
└─────────────────────────────┘

• An abstract class name is written in italics (or tagged {abstract}).
• An interface is shown with the guillemet stereotype «interface» above the name.
• A static member is shown underlined.

3. Visibility (Access) Symbols

MCQ Trap: # is protected, not private. - is private. ~ (package) is a Java concept most C++-focused CSS papers rarely test but may appear as a distractor option.

4. Multiplicity Notation

Written at each end of a relationship line — tells how many objects of one class relate to how many of another.

Example: Department 1 ────── 1..* Professor reads as "one Department has one-or-more Professors."

5. Relationship Notation — The Big Table

This is the direct visual counterpart to the Object Relationships table on Chapter 6. Same four concepts, now drawn as lines:

5.1 Diamond memory hook

• ◇ Hollow diamond = Aggregation = "loose" ownership. Think of the diamond as "not fully colored in" — the relationship isn't fully committed, the part can survive without the whole.
• ◆ Filled diamond = Composition = "tight" ownership. The diamond is "solid/complete" — just like the part's lifetime is completely locked to the whole.
• The diamond always sits next to the "whole"/container class, never the "part" class.

5.2 Visual layout for the three core relationships

Association:     Teacher ──────────────── Student

Aggregation:     Department ◇──────────── Professor
                  (whole)                  (part, can exist independently)

Composition:     Car ◆──────────────────── Engine
                  (whole)                  (part, destroyed with whole)

Inheritance:     Animal △───────────────── Dog
                 (base)  (hollow triangle    (derived)
                          points to base)

Realization:     «interface»
                 Shape  △┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄  Circle
                        (dashed + hollow      (implements)
                         triangle)

6. Worked Example — Mapping C++ Code to a UML Diagram

Using the exact classes from Chapter 6's Object Relationships section:

class Student { };

class Teacher {
public:
    void teach(Student& s);   // Association
};

class Professor { };

class Department {
    vector<Professor*> professors;   // Aggregation — pointers, not owned
};

class Engine { };

class Car {
    Engine engine;   // Composition — owned member object
};

Equivalent UML:

Teacher ──────────────────── Student
   (association: "teaches")

Department ◇──── 1..* ──── Professor
   (aggregation)

Car ◆──── 1 ──── Engine
   (composition)

7. Class Diagram vs Object Diagram

8. Where UML Fits in the SDLC

• Drawn primarily during the Design phase of the Software Development Life Cycle (see the Software Engineering page for full SDLC coverage).
• Acts as a communication bridge between requirements (what the system must do) and implementation (the actual code).
• Class diagrams map almost directly onto C++/Java class declarations — this is why CSS OOP papers pair UML questions with code-writing questions.

Exam Angle

• CSS Computer Science (Paper-I) MCQs commonly test: the meaning of + - # ~, which diamond is hollow vs filled, and which arrow means inheritance vs interface realization.
• A frequently asked short question: "Differentiate between Aggregation and Composition using UML notation." — Answer using the hollow-vs-filled diamond distinction plus the Chapter 6 lifetime-dependency argument.
• Be ready to draw a simple class box for a given scenario (e.g., a BankAccount class) with correct visibility symbols.

MCQ Traps

• ❌ "A filled diamond represents Association" → Wrong. Filled diamond = Composition. Association has no diamond at all.
• ❌ "The triangle for inheritance is filled/solid" → Wrong. The inheritance (generalization) triangle is hollow/open. A filled/solid arrowhead is not used for inheritance in standard UML.
• ❌ "# means private" → Wrong. # = protected. - = private.
• ❌ "Dependency and Association use the same line style" → Wrong. Association is a solid line; Dependency is a dashed line.
• ❌ "Realization and Inheritance both use solid lines" → Wrong. Inheritance = solid line + hollow triangle. Realization = dashed line + hollow triangle.

Important MCQs

1. Who are considered the primary creators ("Three Amigos") of UML?

   Answer: Grady Booch, Ivar Jacobson, and James Rumbaugh

2. In a UML class box, which compartment lists the operations?

   Answer: The bottom (third) compartment

3. Which visibility symbol represents a protected member?

   A) + B) - C) # D) ~

4. A hollow diamond in a UML class diagram represents:

   A) Composition B) Aggregation C) Inheritance D) Dependency

5. Which arrowhead style represents inheritance (generalization)?

   Answer: A hollow/open triangle pointing toward the base class

6. What distinguishes Realization from Inheritance notation?

   Answer: Realization uses a dashed line with a hollow triangle; Inheritance uses a solid line with a hollow triangle

7. Multiplicity 1..* means:

   Answer: One or many (at least one)

8. A static member in a UML class diagram is shown:

   Answer: Underlined

9. Which UML diagram type is classified as "behavioral" rather than "structural"?

   A) Class diagram B) Sequence diagram C) Component diagram D) Deployment diagram

10. In Car ◆── Engine, which class is the "whole"?

    Answer: Car (the diamond sits next to the whole/container class)

Self-Test Questions

1. Draw the three-compartment class box for a BankAccount class with a private balance (double) and a public deposit(amount : double) : void method.
2. Explain, using UML notation only (no code), why Aggregation uses a hollow diamond and Composition uses a filled diamond.
3. What is the visual difference between how UML represents Inheritance and how it represents Interface Realization?
4. If Library ◇── 0..* ── Book, what does the 0..* tell you about how many books a library can have?
5. Convert the Department/Professor aggregation code from Chapter 6 into a one-line UML relationship diagram, including multiplicity.

---

Cross-reference: for the code-level treatment of these same relationships (Association/Aggregation/Composition with working C++ examples and their own MCQs), see the "Object Relationships, Side by Side" section on "6. Classes Advanced."