Project: A Domain Class Diagram

Project: A Domain Class Diagram

Over the previous nine lessons you have mastered every building block of UML class diagrams: classes and their compartments, finding classes in requirements, associations with multiplicity, aggregation and composition, generalization, association classes, dependencies, interfaces, abstract classes, and the object diagram. This final lesson brings everything together into a single, realistic project — building a complete domain class diagram from a real-world business scenario.

A domain class diagram is the analyst's primary deliverable at the end of the analysis phase. It captures the vocabulary of the problem domain — every significant concept, its attributes, and the relationships between concepts — without committing to any specific technology or database design. Think of it as a precise, visual requirements document that both business stakeholders and developers can read.

The Scenario: A Clinic Appointment Booking System

You have interviewed the clinic manager and collected the following requirements. Read them carefully — your task is to model them as a domain class diagram.

1. The clinic has multiple doctors. Each doctor has a name, a specialization (e.g., cardiology), a license number, and a working schedule.
2. Patients register with the clinic. Each patient has a name, a date of birth, a contact phone number, and an insurance policy number.
3. A patient can book one or more appointments. Each appointment records a date, a start time, a status (scheduled / completed / cancelled), and a reason for visit.
4. Each appointment is with exactly one doctor.
5. During a completed appointment, the doctor may create a medical record. The record contains a diagnosis, prescribed medications, and follow-up instructions. Each medical record belongs to exactly one patient.
6. The clinic groups doctors into departments (e.g., Cardiology, Orthopaedics). A department has a name and a head doctor. Each doctor belongs to exactly one department.
7. Both patients and doctors are persons. All persons have a name and an email address managed by the system.
8. The clinic offers various services (e.g., blood test, X-ray, consultation). An appointment may include one or more services, and each service records its fee for billing purposes. The combination of appointment and service also records whether the service was actually performed.
9. The system uses a notification mechanism. Notifications are either SMS or email messages. Each notification is sent to one person and relates to one appointment.

Step 1 — Identify the Classes

Scanning the requirements for nouns yields the candidate class list:

• Person (abstract — requirement 7)
• Patient (specializes Person)
• Doctor (specializes Person)
• Appointment
• MedicalRecord
• Department
• Service
• Notification (abstract — requirement 9 hints at two subtypes)
• SmsNotification and EmailNotification

Nouns that are attributes rather than classes: specialization, license number, diagnosis, fee — these become attribute fields, not boxes.

Step 2 — Assign Attributes and Operations

• Person: - name: String, - email: String
• Patient: - dateOfBirth: Date, - phone: String, - insurancePolicyNo: String
• Doctor: - specialization: String, - licenseNo: String
• Department: - name: String
• Appointment: - date: Date, - startTime: Time, - status: String, - reasonForVisit: String
• MedicalRecord: - diagnosis: String, - medications: String, - followUpInstructions: String
• Service: - serviceName: String, - standardFee: Decimal
• Notification: - sentAt: DateTime, - message: String
• SmsNotification: - phoneNumber: String
• EmailNotification: - toAddress: String

Step 3 — Map the Relationships

Working through the requirements one by one:

• Person → Patient / Doctor: Generalization (hollow-triangle arrows pointing to Person). Person is abstract.
• Department ◆→ Doctor: Composition — a Doctor exists within a Department; 1 Department to 1..* Doctors.
• Department → Doctor (head): Association — the "head doctor" role is a directed association from Department to Doctor with role name headDoctor, multiplicity 1.
• Patient → Appointment: Association — a Patient books appointments; 1 Patient, 0..* Appointments.
• Doctor → Appointment: Association — each Appointment involves exactly 1 Doctor; a Doctor has 0..* Appointments.
• Appointment → MedicalRecord: Association — 0..1 MedicalRecord per Appointment (only completed ones get a record); MedicalRecord belongs to 1 Appointment.
• MedicalRecord → Patient: Association — each MedicalRecord belongs to 1 Patient; a Patient has 0..* records.
• Appointment ↔ Service: Association class AppointmentService — carries performed: Boolean and chargedFee: Decimal. Multiplicity: Appointment 1 — * Service (many services per appointment; a service appears in many appointments).
• Notification → Person: Association — each Notification is sent to 1 Person; 0..* Notifications per Person.
• Notification → Appointment: Association — each Notification relates to 1 Appointment; 0..* Notifications per Appointment.
• Notification → SmsNotification / EmailNotification: Generalization. Notification is abstract.

The Complete Domain Class Diagram

The diagram below renders the full model. Read it top-down: the abstract Person hierarchy on the left, the Department-Doctor composition in the centre-top, the booking chain (Patient → Appointment → MedicalRecord) across the middle, the association class for services at the bottom, and the notification hierarchy on the right.

Step 4 — Reviewing and Validating the Model

Before handing the diagram to stakeholders or developers, run through this checklist:

1. Every requirement is traceable. Each of the nine requirement statements maps to at least one class, attribute, or relationship in the diagram. If a requirement has no corresponding element, the model is incomplete.
2. Multiplicity is correct at both ends. Read every association in both directions: "one Patient has zero or more Appointments" and "each Appointment belongs to exactly one Patient." Both directions should make business sense.
3. No attribute masquerades as a class. "Diagnosis" is a field on MedicalRecord, not a separate class, because it has no relationships and no operations of its own.
4. Generalization passes the is-a test. Patient is a Person. Doctor is a Person. SmsNotification is a Notification. All hold.
5. Association class is justified. AppointmentService has its own attributes (performed, chargedFee) that belong neither to Appointment nor to Service alone — they only make sense on the link between the two. This justifies the association class.
6. Abstract classes are never instantiated. No business rule creates a bare Person or bare Notification — only subtype instances exist in the system.

Common Mistakes in Domain Class Diagrams

• Missing multiplicity. An unlabeled line is ambiguous. Always annotate both ends.
• Putting everything in one giant class. If a class has more than eight or ten attributes, look for hidden sub-concepts that should be extracted.
• Overusing composition. Use filled diamonds (composition) only when the child literally cannot exist without the parent — not merely when one "belongs to" another in a loose sense.
• Forgetting the association class. When a many-to-many relationship carries its own data, that data must live in an association class, not shoehorned into either participant.
• Confusing analysis with design. The domain class diagram does not show primary keys, foreign keys, tables, or framework-specific types. Keep it technology-neutral during analysis.

What Comes Next

You have now completed the UML Class and Object Diagrams tutorial. Your domain class diagram is the foundation for two downstream activities covered in the next tutorials:

• Database design — mapping classes to tables, generalizations to table strategies, and association classes to junction tables.
• Behavioral modeling — sequence diagrams and state machines that show how these classes interact at runtime.

Keep this clinic diagram as your reference artifact. In every project you take on as an analyst, the domain class diagram will be the single document that most clearly communicates the structure of the problem to every stakeholder on the team.