UML class diagram — class, association, aggregation, composition আর inheritance

১ · Class diagram কেন — কোডের মানচিত্র

একটি কাল্পনিক বাস-টিকিট অ্যাপের কথা ভাবুন। ঈদের আগে এক সপ্তাহে লাখো মানুষ টিকিট কাটেন, অ্যাপের কোড প্রায় চল্লিশ হাজার লাইন। দলে নতুন একজন developer এলেন। প্রথম দিন তিনি জানতে চাইলেন: “একটি টিকিট কি একটি আসনের সাথে যুক্ত, নাকি একটি যাত্রার সাথে? বাস বাতিল হলে আসনের রেকর্ডের কী হয়? ছাত্র-টিকিট কি আলাদা class, নাকি শুধু একটি flag?” এই প্রশ্নগুলোর উত্তর কোডের কোথাও না কোথাও আছে — কিন্তু চল্লিশ হাজার লাইন পড়ে বের করতে কয়েক দিন লাগবে।

দলের lead হোয়াইটবোর্ডে দশটি বাক্স আর কয়েকটি রেখা আঁকলেন। পনেরো মিনিটে নতুন developer পুরো system-এর কাঠামো বুঝে গেলেন। সেই ছবিটিই class diagram.

পর্ব ২৩-এ (Requirement modeling) আপনি domain model দেখেছেন — বাক্সে শুধু নাম আর attribute, রেখায় multiplicity. সেখানে UML-এর ইতিহাস আর use case diagram-ও বলা হয়েছে, তাই এখানে আর বলছি না। সেটি ছিল class diagram-এর একটি হালকা অংশ। এই পর্বে পুরো নোটেশন: operation, visibility, interface, পাঁচ রকম সম্পর্ক, আর কোডের সাথে diagram-এর মিল-অমিল।

Class diagram কোথায় কাজে লাগে, তার একটি তালিকা:

২ · একটি class-এর বাক্স — নাম, attribute আর operation

UML-এ একটি class একটি আয়তক্ষেত্র, সাধারণত তিনটি ঘরে (compartment) ভাগ করা: ওপরে নাম, মাঝে attribute, নিচে operation. নিচের ছবিতে কাল্পনিক বাস-টিকিট অ্যাপের Ticket class পূর্ণ নোটেশনে, আর পাশে দুটি বিশেষ ধরনের বাক্স।

Attribute আর operation-এর syntax

UML 2.5.1-এ (OMG-র সর্বশেষ প্রকাশিত সংস্করণ, ২০১৭) একটি attribute-এর লেখার ছাঁচ, যেখানে বন্ধনীর অংশ ঐচ্ছিক:

visibility name : Type [multiplicity] = default {property}
উদাহরণ:   - seatNo : String [0..1]
          - stops : Stop [2..*] {ordered}

visibility name(param : Type, …) : ReturnType
উদাহরণ:   + pay(method : PaymentMethod) : Receipt

• Multiplicity না লিখলে ধরা হয় [1] — অর্থাৎ ঠিক একটি মান। [0..1] মানে মান না-ও থাকতে পারে (কোডে null বা None), [*] মানে একটি সংগ্রহ।
• Default (= BOOKED) হলো object তৈরির সময়ের শুরুর মান।
• Property বাঁকা বন্ধনীতে: {readOnly} — একবার বসলে বদলায় না; {ordered} — সংগ্রহের ক্রমের অর্থ আছে (রুটের stop-গুলো ক্রমে)।
• Derived attribute-এর আগে /: / totalFare : Money — রাখা হয় না, হিসাব করে পাওয়া যায়।
• Operation-এর return type না থাকলে কিছুই লেখা হয় না (অনেক বই আর tool : void লেখে — UML-এ বাধ্যতামূলক নয়)। Parameter-এর আগে দিক লেখা যায় (in, out, inout), ডিফল্ট in.

Visibility, static আর abstract

হাতে আঁকার সময় italic বোঝা কঠিন, তাই অনেকে abstract class-এর নামের নিচে {abstract} লেখেন — UML 2.5.1 দুটোই মেনে নেয়।

«interface», «enumeration» আর stereotype

দুই কোণা বন্ধনী (guillemet) «…»-এ লেখা শব্দ বাক্সের ধরন বা বাড়তি অর্থ বলে। «interface» লেখা বাক্স একটি interface — শুধু operation-এর চুক্তি; «enumeration» লেখা বাক্স একটি enumeration — নির্দিষ্ট কয়েকটি মান। কঠোরভাবে বললে UML-এ এ দুটি keyword; আর «entity», «use»-এর মতো লেবেলগুলো stereotype. দেখতে একই, তাই দৈনন্দিন কথায় সবাইকেই “stereotype” বলা হয়।

শেষ কথা: সব ঘর সবসময় দেখাতে হয় না। UML ঘর লুকিয়ে রাখার (suppress) অনুমতি দেয়। আলোচনার ছবিতে শুধু নাম, বা নাম আর মূল কয়েকটি attribute — এটাই সাধারণ চর্চা। প্রতিটি getter-setter লেখা বাক্স তথ্য বাড়ায় না, ছবিটা ঢেকে দেয়।

৩ · Association — কে কাকে চেনে, কতজনকে

দুটি class-এর বাক্সের মাঝে একটি সাধারণ রেখা মানে association: এক class-এর object অন্য class-এর object-এর সাথে দীর্ঘস্থায়ীভাবে যুক্ত থাকতে পারে। কোডে সাধারণত এটি একটি field — Ticket-এর ভেতরে passenger. রেখাটির চারপাশে কয়েকটি তথ্য লেখা যায়:

• Association-এর নাম রেখার মাঝখানে, পাশে ছোট ভরাট ত্রিভুজ পড়ার দিক দেখায়: “Passenger holds ▶ Ticket”.
• Role name প্রান্তে: +passenger — Ticket-এর চোখে ওই প্রান্তের object-টির ভূমিকা। কোডে প্রায়ই এটিই field-এর নাম, আর সামনে visibility-ও বসে।
• Multiplicity প্রান্তে: ওই প্রান্তের কতগুলো object অন্য প্রান্তের একটি object-এর সাথে যুক্ত থাকতে পারে।
• Navigability: প্রান্তে খোলা তীরের মাথা মানে “এই দিকে যাওয়া যায়” — Ticket থেকে Passenger খুঁজে পাওয়া যায়। প্রান্তে ছোট × মানে স্পষ্টভাবে “যাওয়া যায় না”। কোনো চিহ্ন না থাকলে বিষয়টি নির্দিষ্ট করা হয়নি — দুই দিকই বোঝায় না।

পড়ার নিয়মটি পর্ব ২৩-এর মতোই: যে প্রান্তে সংখ্যা লেখা, সেটি সেই প্রান্তের class-এর সংখ্যা। “Booking 1 —— 1..* Ticket” পড়ুন দুবার: “একটি Booking-এর সাথে এক বা একাধিক Ticket”; “একটি Ticket-এর সাথে ঠিক একটি Booking”. Multiplicity শুধু সাজসজ্জা নয় — এটি ব্যবসার নিয়ম। “এক booking-এ সর্বোচ্চ চারটি টিকিট” নিয়মটি কোনো developer-এর মাথায় না থাকলেও diagram-এ লেখা থাকে।

Association class আর qualified association

কখনো সম্পর্কটির নিজেরই তথ্য থাকে। একজন যাত্রী অনেক যাত্রায় যান, একটি যাত্রায় অনেক যাত্রী — Passenger * —— * Trip. কিন্তু “ভাড়া কত, কোন আসন” তথ্যটি যাত্রীরও নয়, যাত্রারও নয় — এই নির্দিষ্ট জোড়াটির। তখন একটি association class আঁকা হয়: একটি class-এর বাক্স, ড্যাশ রেখা দিয়ে association-এর রেখার মাঝখানে জোড়া। আমাদের Ticket আসলে এমনই একটি জিনিস। কোডে প্রায় সবসময় এটি একটি সাধারণ class হয়ে যায়, যার দুটি field — ডাটাবেসের “join table”-এর মতো।

Qualified association-এ এক প্রান্তে ছোট একটি বাক্সে চাবি লেখা থাকে। “Trip [seatNo] —— 0..1 Ticket” মানে: একটি যাত্রা আর একটি আসন নম্বর দিলে সর্বোচ্চ একটি টিকিট পাওয়া যায়। চাবি ছাড়া একটি যাত্রার টিকিট *; চাবিসহ 0..1. অর্থাৎ “একই যাত্রায় একই আসন দুবার বিক্রি নয়” নিয়মটি ছবিতেই লেখা হয়ে গেল। কোডে এটি প্রায়ই একটি dictionary বা map: tickets_by_seat: dict[str, Ticket].

Multiplicity যাচাই — একটি ছোট checker

Diagram-এর multiplicity আর বাস্তব data মেলে কি না, তা যন্ত্র দিয়েও দেখা যায়। নিচের কোডে model-এর প্রতিটি association-প্রান্তের নিয়ম একটি তালিকায়, আর কয়েকটি object ও তাদের link আরেকটি তালিকায়। কোডটি প্রতিটি object-এর link গুনে নিয়মের সাথে মেলায়। এর আকার পর্ব ২৩-এর Order 1 — 1..* OrderLine-এর মতোই, শুধু এখানে Booking আর Ticket.

// Multiplicity checker for a tiny fictional bus-ticket model.
// Each association end: "how many <to> may one <from> be linked to?"
const ends = [
  { from: "Booking", to: "Ticket",    m: "1..*" },  // a booking has 1 or more tickets
  { from: "Ticket",  to: "Booking",   m: "1"    },  // each ticket is in exactly 1 booking
  { from: "Ticket",  to: "Passenger", m: "1"    },
  { from: "Ticket",  to: "Seat",      m: "0..1" },  // seat may be chosen later
];
const range = m => { const [lo, hi = lo] = (m === "*" ? "0..*" : m).split(".."); return [+lo, hi === "*" ? Infinity : +hi]; };
// Instances: [id, class] and links [a, b] (a link is navigable both ways here)
const objs = [["bk1","Booking"],["bk2","Booking"],["bk3","Booking"],["t1","Ticket"],["t2","Ticket"],
              ["t3","Ticket"],["p1","Passenger"],["s1","Seat"],["s2","Seat"]];
const links = [["bk1","t1"],["bk1","t2"],["bk2","t2"],["t1","p1"],["t2","p1"],
               ["t1","s1"],["t1","s2"],["t3","p1"]];
const cls = Object.fromEntries(objs);
let bad = 0;
for (const e of ends) {
  const [lo, hi] = range(e.m);
  for (const [id, c] of objs) {
    if (c !== e.from) continue;
    const n = links.filter(l => l.includes(id))
                   .map(l => (l[0] === id ? l[1] : l[0])).filter(o => cls[o] === e.to).length;
    if (n < lo || n > hi) {
      bad++;
      console.log(`VIOLATION ${id}:${c} has ${n} ${e.to} (allowed ${e.m})`);
    }
  }
}
console.log(bad ? `${bad} violation(s)` : "model satisfied");

VIOLATION bk3:Booking has 0 Ticket (allowed 1..*)
VIOLATION t2:Ticket has 2 Booking (allowed 1)
VIOLATION t3:Ticket has 0 Booking (allowed 1)
VIOLATION t1:Ticket has 2 Seat (allowed 0..1)
4 violation(s)

৪ · Aggregation আর composition — অংশ আর সমগ্র

কিছু association-এ একটি জিনিস অন্যটির অংশ: বাসের আসন, রুটের stop. UML এর জন্য দুটি বিশেষ রূপ দেয়, দুটিতেই হীরা (diamond) বসে সমগ্রের (whole) প্রান্তে।

UML 2.5.1-এর composition-এর নিয়ম দুটি: অংশটি এক সময়ে সর্বোচ্চ একটি composite-এর; আর composite মুছলে তার সব অংশ-object তার সাথে মুছে যায়। একটি সূক্ষ্মতা: মোছার আগে একটি অংশকে সরিয়ে নেওয়া যায় — তখন সেটি বাঁচে। একটি বাস বিক্রির আগে একটি আসন খুলে অন্য বাসে লাগালে আসনটির মালিক বদলায়, কিন্তু দুই বাসের একসাথে নয়।

Composition আর aggregation-এর আসল পার্থক্য জীবনচক্রে, তাই কোডে চালিয়েই দেখা ভালো। নিচের কোডে alive নামের একটি set সব “বেঁচে থাকা” object রাখে। Bus নিজেই আসন তৈরি করে আর মোছে; Route শুধু আগে থেকে থাকা stop-গুলোর দিকে ইঙ্গিত রাখে।

// Composition (Bus owns its Seats) vs aggregation (a Route groups shared Stops).
const alive = new Set();                       // every object that still exists
class Seat { constructor(no) { this.no = no; this.bus = null; alive.add(this); } }
class Bus {                                    // composite: creates and destroys parts
  constructor(reg, n) {
    this.reg = reg; this.seats = []; alive.add(this);
    for (let i = 1; i <= n; i++) this.attach(new Seat(reg + "-S" + i));
  }
  attach(seat) {                               // a part has at most one whole
    if (seat.bus && seat.bus !== this) throw new Error(seat.no + " already belongs to " + seat.bus.reg);
    seat.bus = this; this.seats.push(seat);
  }
  destroy() { this.seats.forEach(s => alive.delete(s)); this.seats = []; alive.delete(this); }
}
class Stop { constructor(name) { this.name = name; alive.add(this); } }
class Route {                                  // aggregate: only refers to stops
  constructor(name, stops) { this.name = name; this.stops = stops; alive.add(this); }
  destroy() { alive.delete(this); }            // the stops are NOT deleted
}
const count = (C) => [...alive].filter(o => o instanceof C).length;
const show = (t) => console.log(t.padEnd(26), "buses", count(Bus), "seats", count(Seat),
                                "routes", count(Route), "stops", count(Stop));
const b1 = new Bus("DHA-11", 3), b2 = new Bus("DHA-12", 2);
const gabtoli = new Stop("Gabtoli"), savar = new Stop("Savar"), aricha = new Stop("Aricha");
const r1 = new Route("Dhaka-Aricha", [gabtoli, savar, aricha]);
const r2 = new Route("Dhaka-Savar", [gabtoli, savar]);   // shares two stops
show("start");
try { b2.attach(b1.seats[0]); } catch (e) { console.log("refused:", e.message); }
b1.destroy();  show("after b1.destroy()");
r1.destroy();  show("after r1.destroy()");
console.log("r2 still has:", r2.stops.map(s => s.name).join(", "));

start                      buses 2 seats 5 routes 2 stops 3
refused: DHA-11-S1 already belongs to DHA-11
after b1.destroy()         buses 1 seats 2 routes 2 stops 3
after r1.destroy()         buses 1 seats 2 routes 1 stops 3
r2 still has: Gabtoli, Savar

৫ · Generalization, realization আর dependency

বাকি তিনটি সম্পর্ক “কে কার অংশ” নয় — “কে কোন ধরনের” আর “কে কার ওপর নির্ভর করে”।

• Generalization: সাধারণ রেখা, সাধারণ class-এর দিকে ফাঁপা ত্রিভুজ। StudentTicket একটি বিশেষ ধরনের Ticket — “is-a” সম্পর্ক। কোডে এটি inheritance: Java-তে extends, Python-এ class StudentTicket(Ticket). Subclass যেন সত্যিই superclass-এর জায়গায় বসতে পারে — সেই শর্তটি Liskov substitution, পর্ব ২৮-এ (SOLID ২)।
• Realization: ড্যাশ রেখা, interface-এর দিকে ফাঁপা ত্রিভুজ। WalletPayment «interface» PaymentMethod-এর চুক্তি পূরণ করে। Java-তে implements; Python-এ Protocol বা abstract class. বিকল্প নোটেশন “lollipop”: class থেকে একটি ছোট বৃত্ত বের হয়, পাশে interface-এর নাম।
• Dependency: ড্যাশ রেখা, যাকে ব্যবহার করা হয় তার দিকে খোলা তীর। সবচেয়ে দুর্বল সম্পর্ক: একটি class অন্যটিকে অল্প সময়ের জন্য ব্যবহার করে — parameter, local variable, বা static call — field হিসেবে ধরে রাখে না। পাশে keyword লেখা যায়: «use», «create». অর্থ: “সরবরাহকারী বদলালে এটিও বদলাতে পারে।”

নিচের stepper-এ ছয়টি রেখা একটি একটি করে আসবে। প্রতিটির তীর বা হীরা কোন প্রান্তে, সেটি খেয়াল করুন।

শক্তির ক্রমে সাজালে: dependency (সবচেয়ে দুর্বল) < association < aggregation < composition; আর generalization সবচেয়ে শক্ত বাঁধন, কারণ subclass superclass-এর ভেতরের খুঁটিনাটিও উত্তরাধিকারে পায়। একটি diagram-এ কোনো class-এর দিকে যত বেশি রেখা, সেটি বদলানো তত ঝুঁকিপূর্ণ — পর্ব ২৫-এর (coupling আর cohesion) মাপকাঠি এখানে চোখেই দেখা যায়।

৬ · পূর্ণ ছবি — বর্ণনা থেকে class diagram

এবার সব নোটেশন একসাথে। নিচের ছবিটি কাল্পনিক বাস-টিকিট অ্যাপের মূল অংশ — এতে ছয় রকম সম্পর্কের প্রতিটি অন্তত একবার আছে। Attribute আর operation লুকানো রাখা হয়েছে, যাতে কাঠামোটি পরিষ্কার দেখা যায়।

ছবিটি পড়ে কয়েকটি বাক্য বলা যায়, যা কোড না দেখেই নতুন developer জানলেন: প্রতিটি টিকিট ঠিক একজন যাত্রীর আর ঠিক একটি যাত্রার; ছাত্র-টিকিট একটি বিশেষ টিকিট; টিকিট পেমেন্টের জন্য একটি PaymentMethod ব্যবহার করে কিন্তু ধরে রাখে না; mobile wallet সেই চুক্তির একটি বাস্তবায়ন; একটি বাসের আসনগুলো বাসেরই অংশ; রুট stop-গুলোকে ভাগ করে নেয়। তীরের দিক থেকে আরও বোঝা যায়: Passenger তার টিকিটের তালিকা নিজে রাখে না — “এই যাত্রীর সব টিকিট” পেতে হলে টিকিটগুলো খুঁজতে হবে (কোডে প্রায়ই একটি query দিয়ে)। এটি একটি নকশার সিদ্ধান্ত, আর ছবিতে স্পষ্ট।

এবার উল্টো কাজ — একটি লেখা বর্ণনা থেকে নিজে diagram আঁকা। পরীক্ষা আর ইন্টারভিউর সবচেয়ে চেনা প্রশ্ন এটিই। বর্ণনা (একটি কাল্পনিক জেলা গণগ্রন্থাগার): “প্রতিটি সদস্যের নাম আর ফোন নম্বর রাখা হয়। একজন সদস্য একসাথে সর্বোচ্চ তিনটি বই ধার নিতে পারেন, প্রতিটি ধারের ফেরতের তারিখ থাকে। গ্রন্থাগারে প্রতিটি বইয়ের (title আর ISBN) এক বা একাধিক কপি থাকে, প্রতিটি কপির একটি barcode. ধার দেওয়া হয় একটি নির্দিষ্ট কপি। কোনো বই catalogue থেকে বাদ দিলে তার কপিগুলোর রেকর্ডও বাদ যায়। ছাত্র-সদস্য একটি বিশেষ সদস্য, তাঁর student ID রাখা হয়।”

৭ · কোড থেকে diagram — Java আর Python

বাস্তবে প্রায়ই উল্টো দিক থেকে কাজ হয়: কোড আগে থেকেই আছে, আর আপনাকে তার ছবি আঁকতে হবে — নতুন দলে যোগ দিয়ে, কোড review-তে, বা পুরোনো system বোঝার সময় (reverse engineering বলা হয়)। মিলের মূল নিয়মগুলো:

একটি field-কে attribute হিসেবে লিখবেন, না association-এর রেখা হিসেবে? নিয়ম: মানটি যদি একটি সাধারণ data type হয় (String, Integer, Date, Money), attribute; যদি diagram-এর আরেকটি class হয়, রেখা। দুটোই একসাথে লিখবেন না — - seat : Seat attribute আর Seat-এর দিকে রেখা দিলে একই তথ্য দুবার, আর পাঠক ভাববেন দুটি আলাদা সম্পর্ক।

নিচের stepper-এ একটি ছোট Java কোড লাইন ধরে ধরে diagram-এ অনুবাদ হচ্ছে।

1public abstract class Vehicle {2    protected String regNo;3    public abstract int seatCount();4}5public class Bus extends Vehicle {6    private final List<Seat> seats = new ArrayList<>();7    private Driver driver;    // may be null8    private static int busCount = 0;9    public int seatCount() { return seats.size(); }10    public Receipt sell(PaymentMethod m) { /* ... */ }11}12class Seat { String no; }13class WalletPayment implements PaymentMethod { /* ... */ }

Python দিয়ে নিজেই diagram বানানো

Python-এ class নিজেই নিজের সম্পর্কে অনেক কিছু বলে দেয়: __annotations__-এ type hint, __bases__ আর __mro__-এ উত্তরাধিকার, inspect module দিয়ে method-এর signature. নিচের কোড কয়েকটি class পড়ে PlantUML-এর মতো লেখায় একটি class diagram ছাপে। Python-এ সত্যিকারের visibility নেই, তাই কোডটি নামের রীতি ধরে নেয় (এটা আমাদের বেছে নেওয়া নিয়ম, ভাষার নিয়ম নয়): এক underscore _x হলে #, name mangling হওয়া __x হলে -, বাকি সব +. typing.is_protocol Python ৩.১৩ থেকে আছে।

import inspect, typing; from abc import ABC, abstractmethod
class PaymentMethod(typing.Protocol):            # an interface
    def pay(self, amount: int) -> str: ...
class Wallet(PaymentMethod):                     # realizes the interface
    def pay(self, amount: int) -> str: return "OK"
class Seat:
    no: str; held_by: str | None                 # "X | None" -> [0..1]
class Bus(ABC):                                  # abstract class
    seats: list[Seat]                            # list -> [*]
    @abstractmethod
    def capacity(self) -> int: ...
class AcBus(Bus):
    _fare_rate: int                              # one "_"  -> protected (#)
    def capacity(self) -> int: return len(self.seats)
    def __check(self, seat_no: str) -> bool: return True   # "__" -> private (-)
def vis(n): return "#" if n.startswith("_") else "+"     # naming convention!
def typ(t):
    a, o = typing.get_args(t), typing.get_origin(t)
    return a[0].__name__ + (" [*]" if o is list else " [0..1]") if a else t.__name__
for c in (PaymentMethod, Wallet, Seat, Bus, AcBus):
    print("interface" if typing.is_protocol(c) else "abstract class" if inspect.isabstract(c) else "class", c.__name__, "{")
    for n, t in (ann := inspect.get_annotations(c)).items():   # own __annotations__
        print(f"  {vis(n)}{n.lstrip('_')} : {typ(t)}")
    for n, f in vars(c).items():
        if not inspect.isfunction(f) or n.endswith("__"): continue
        p = "_" + c.__name__ + "__"; s = inspect.signature(f)   # __x is stored as _Class__x
        v, n = ("-", n[len(p):]) if n.startswith(p) else (vis(n), n.lstrip("_"))
        ps = ", ".join(f"{k} : {q.annotation.__name__}" for k, q in list(s.parameters.items())[1:])
        print(f"  {v}{n}({ps}) : {s.return_annotation.__name__}" + (" {abstract}" if getattr(f, "__isabstractmethod__", 0) else ""))
    print("}")
    for b in [b for b in c.__bases__ if b not in (object, ABC, typing.Protocol)]:
        print(f"{b.__name__} {'<|..' if typing.is_protocol(b) else '<|--'} {c.__name__}")
    for n, t in ann.items():
        if typing.get_origin(t) is list: print(f'{c.__name__} --> "*" {typ(t)[:-4]} : {n}')
print("MRO of AcBus:", " -> ".join(k.__name__ for k in AcBus.__mro__))

interface PaymentMethod {
  +pay(amount : int) : str
}
class Wallet {
  +pay(amount : int) : str
}
PaymentMethod <|.. Wallet
class Seat {
  +no : str
  +held_by : str [0..1]
}
abstract class Bus {
  +seats : Seat [*]
  +capacity() : int {abstract}
}
Bus --> "*" Seat : seats
class AcBus {
  #fare_rate : int
  +capacity() : int
  -check(seat_no : str) : bool
}
Bus <|-- AcBus
MRO of AcBus: AcBus -> Bus -> ABC -> object

৮ · Object diagram — একটি মুহূর্তের ছবি

Class diagram বলে কী সম্ভব; object diagram বলে একটি নির্দিষ্ট মুহূর্তে কী আছে। এটি যেন রেলের সময়সূচি আর আজ সকাল সাতটায় কমলাপুর স্টেশনের একটি ছবির পার্থক্য। নোটেশন class diagram-এর মতোই, তিনটি পার্থক্যসহ:

• বাক্সের নাম objectName : ClassName, নিচে দাগ দেওয়া। নাম না জানলে শুধু : Ticket.
• Attribute-এর জায়গায় slot — নির্দিষ্ট মান: fare = 850. Type লেখার দরকার নেই।
• রেখাগুলো link — association-এর একটি করে উদাহরণ। এতে multiplicity লেখা হয় না, কারণ এখানে সংখ্যা গোনা যায়।

Object diagram-এর সবচেয়ে বড় কাজ class diagram পরীক্ষা করা। একটি বাস্তব পরিস্থিতি আঁকতে গিয়ে যদি দেখেন কোনো নিয়ম ভাঙতে হচ্ছে — যেমন একটি পরিবারের চারজনের জন্য একটি booking, অথচ class diagram-এ লেখা Booking 1 —— 1 Ticket — তাহলে class diagram-টি ভুল। কঠিন multiplicity নিয়ে stakeholder-এর সাথে আলোচনায়ও এটি কাজের: “এই ছবির মতো কি কখনো হয়?” প্রশ্নটি বিমূর্ত সংখ্যার চেয়ে অনেক সহজে বোঝা যায়।

জীবন্ত object থেকেও object diagram বানানো যায়। নিচের Python কোড কয়েকটি dataclass object-এর ভেতর ঘুরে (vars() দিয়ে) প্রতিটি সাধারণ মানকে slot আর প্রতিটি object-মানকে link হিসেবে PlantUML-এর object-লেখার আকারে ছাপে। এখানের ছোট model-এ Ticket সরাসরি একটি Seat ধরে রাখে, যা ছবি ২৯.২ থেকে একটু আলাদা।

from dataclasses import dataclass, field
@dataclass
class Seat:
    no: str
@dataclass
class Bus:
    reg_no: str
    seats: list[Seat] = field(default_factory=list)
@dataclass
class Passenger:
    name: str
@dataclass
class Ticket:
    fare: int
    passenger: Passenger
    seat: Seat | None = None

bus = Bus("DHA-11", [Seat("A1"), Seat("A2")])
karim = Passenger("Karim")
tickets = [Ticket(850, karim, bus.seats[0]), Ticket(850, karim)]

names, lines, links = {}, [], []
def visit(obj):
    """Walk live objects; plain values become slots, objects become links."""
    if id(obj) in names: return names[id(obj)]
    names[id(obj)] = n = type(obj).__name__.lower() + str(len(names) + 1)
    slots = []
    for k, v in vars(obj).items():
        for item in (v if isinstance(v, list) else [v]):
            if hasattr(item, "__dict__"): links.append(f"{n} -- {visit(item)} : {k}")
            elif item is not None: slots.append(f"  {k} = {item!r}")
    lines.append(f'object "{n} : {type(obj).__name__}" as {n} {{\n' + "\n".join(slots) + "\n}")
    return n
for root in [bus] + tickets: visit(root)
print("\n".join(lines + links))

object "seat2 : Seat" as seat2 {
  no = 'A1'
}
object "seat3 : Seat" as seat3 {
  no = 'A2'
}
object "bus1 : Bus" as bus1 {
  reg_no = 'DHA-11'
}
object "passenger5 : Passenger" as passenger5 {
  name = 'Karim'
}
object "ticket4 : Ticket" as ticket4 {
  fare = 850
}
object "ticket6 : Ticket" as ticket6 {
  fare = 850
}
bus1 -- seat2 : seats
bus1 -- seat3 : seats
ticket4 -- passenger5 : passenger
ticket4 -- seat2 : seat
ticket6 -- passenger5 : passenger

৯ · তিন দৃষ্টিকোণ, চেনা ভুল আর লেখা থেকে diagram

একই বাক্স, তিন স্তরের অর্থ

“Ticket” নামের একটি বাক্স তিনটি ভিন্ন জিনিস বোঝাতে পারে। Martin Fowler UML Distilled-এ (প্রথম সংস্করণ ১৯৯৭) class diagram-এর তিনটি perspective বা দৃষ্টিকোণ ব্যাখ্যা করেন, আর ধারণাটির কৃতিত্ব দেন Steve Cook আর John Daniels-কে (১৯৯৪ সালের বই Designing Object Systems) বলে জানা যায়। পরের সংস্করণে তিনি মূলত conceptual আর software — এই দুই ভাগে কথা বলেন; সংস্করণ মিলিয়ে নিন।

সমস্যা হয় যখন একটি ছবিতে তিন স্তর মিশে যায়: domain model-এ ArrayList, বা আলোচনার ছবিতে প্রতিটি private field. আঁকার আগে নিজেকে জিজ্ঞেস করুন, “এই ছবিটি কে পড়বেন, কোন প্রশ্নের উত্তরে?” ব্যবসার মানুষের সাথে আলোচনায় conceptual; দলের মধ্যে module-এর চুক্তি ঠিক করতে specification (পর্ব ৩১-এর interface আর contract-এর বিষয়); কোনো জটিল অংশ refactor করার আগে implementation.

চেনা ভুল

লেখা থেকে diagram — PlantUML আর Mermaid

হাতে আঁকা ছবি Git-এ রাখলে diff দেখা যায় না, review-ও কঠিন। তাই অনেক দল diagram লেখে সাধারণ text-এ: PlantUML (open-source, ২০০৯ সালের দিকে শুরু বলে জানা যায়) বা Mermaid (JavaScript-এ লেখা; কিছু code-hosting platform README-তে সরাসরি দেখায়)। নিচের দুটি উদাহরণ ছবি ২৯.২-এর একটি অংশ। Syntax সংস্করণ-ভেদে বদলাতে পারে, তাই নিজের tool-এ render করে যাচাই করুন।

@startuml
abstract class Vehicle {
  #regNo : String
  {abstract} +seatCount() : int
}
class Bus {
  -busCount : int {static}
  +seatCount() : int
}
interface PaymentMethod {
  +pay(amount : int) : Receipt
}
enum TicketStatus {
  BOOKED
  PAID
  CANCELLED
}
Vehicle <|-- Bus
Bus "1" *-- "1..*" Seat : seats
Route "0..*" o-- "2..*" Stop
Ticket "0..*" --> "1" Trip
WalletPayment ..|> PaymentMethod
Ticket ..> PaymentMethod : <<use>>
@enduml

classDiagram
  class PaymentMethod {
    <<interface>>
    +pay(amount: int) Receipt
  }
  Vehicle <|-- Bus
  Bus "1" *-- "1..*" Seat : seats
  Route "0..*" o-- "2..*" Stop
  Ticket "0..*" --> "1" Trip
  WalletPayment ..|> PaymentMethod
  Ticket ..> PaymentMethod : uses

দুটিতেই চিহ্নগুলো ছবির মতো: <|-- ত্রিভুজ, *-- ভরাট হীরা, o-- ফাঁপা হীরা, .. ড্যাশ রেখা, > খোলা তীর। হীরা বা ত্রিভুজের চিহ্ন যে নামের পাশে, ছবিতে সেটি সেই বাক্সের প্রান্তে বসে — Bus "1" *-- "1..*" Seat-এ হীরা Bus-এর দিকে। Diagram-টি repository-তে docs/ ফোল্ডারে রাখলে প্রতিটি পরিবর্তন commit আর pull request-এ (পর্ব ১৬) দেখা যায়।

১০ · AI-এর যুগে — AI-এর আঁকা class diagram যাচাই

একটি বর্ণনা বা কোড দিলে AI কয়েক সেকেন্ডে PlantUML লিখে দেয়, আর render করলে ছবিটি খুব পেশাদার দেখায়। কিন্তু UML-এ তীরের একটি মাথা বা হীরার একটি প্রান্ত বদলালেই অর্থ উল্টে যায় — আর এই ভুলগুলো দেখতে নির্দোষ। এই বিষয়ে AI-এর চেনা ভুল:

AI-এর দেওয়া class diagram হাতে পেলে — চেকলিস্ট

• PlantUML/Mermaid কোডটি নিজে render করেছি; কোনো syntax error বা হারানো বাক্স নেই
• প্রতিটি হীরা সমগ্রের প্রান্তে, প্রতিটি ত্রিভুজ সাধারণ class বা interface-এর দিকে, রেখা নিরেট না ড্যাশ — একটি একটি করে যাচাই করেছি
• প্রতিটি multiplicity-র উৎস জানি, আর অন্তত একটি object diagram এঁকে নিয়মগুলো পরীক্ষা করেছি
• কোড থেকে আঁকা হলে, extends, implements, field আর parameter-এর সাথে রেখাগুলো মিলিয়েছি
• ছবিটি কোন দৃষ্টিকোণের (conceptual, specification, implementation), তা ঠিক করে বাড়তি খুঁটিনাটি বাদ দিয়েছি
• AI-কে পাঠানো লেখা থেকে গোপন তথ্য সরিয়েছি, আর বইয়ের বা মানদণ্ডের উল্লেখ নিজে মিলিয়েছি