Requirement modeling — domain model, use case diagram, activity আর state diagram

১ · কেন requirement-এর ছবি আঁকবেন

একটি কাল্পনিক অনলাইন ফার্মেসি অ্যাপের কথা ভাবুন। পর্ব ২০-এ (Requirement engineering) দল stakeholder-দের সাথে কথা বলেছে, পর্ব ২১-এ (Functional আর non-functional requirement) requirement-গুলো মাপা যায় এমনভাবে লিখেছে, আর পর্ব ২২-এ (Use case আর user story) প্রতিটি লক্ষ্যের ধাপগুলো লেখা use case আর user story হয়েছে। এখন হাতে প্রায় চল্লিশ পাতার লেখা।

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

Requirement modeling মানে requirement-কে এক বা একাধিক নির্দিষ্ট নিয়মের ছবি (বা কাঠামোবদ্ধ লেখা) দিয়ে প্রকাশ করা, যাতে তিনটি লাভ হয়:

এক ধরনের ছবি সব প্রশ্নের উত্তর দেয় না। তাই কয়েকটি দৃষ্টিকোণ থেকে model বানানো হয়। এই পর্বে আমরা পাঁচটি দেখব:

২ · UML — তিন পদ্ধতি থেকে একটি ভাষা

১৯৮০-র দশকের শেষ আর ১৯৯০-এর দশকের শুরুতে object-oriented analysis-এর কয়েক ডজন পদ্ধতি ছিল, প্রত্যেকের নিজস্ব ছবি আঁকার নিয়ম। একই class কেউ আঁকতেন মেঘের মতো, কেউ আয়তক্ষেত্রে। একে অনেকে “method war” বলতেন। এর মধ্যে তিনটি পদ্ধতি সবচেয়ে প্রভাবশালী ছিল:

• Grady Booch-এর Booch method — design আর কোডের কাছাকাছি স্তরে শক্তিশালী।
• James Rumbaugh ও সহকর্মীদের OMT (Object Modeling Technique, ১৯৯১-এর বই) — analysis আর data-র কাঠামোয় শক্তিশালী।
• Ivar Jacobson-এর OOSE (১৯৯২-এর বই) — যেখান থেকে use case-এর ধারণা এসেছে। Jacobson Ericsson-এ telecom system-এর কাজের অভিজ্ঞতা থেকে ১৯৮০-র দশকে use case-এর চিন্তা গড়ে তোলেন বলে জানা যায়।

UML ২.৫-এ মোট ১৪ ধরনের diagram আছে — সাতটি কাঠামোর (class, object, component…), সাতটি আচরণের (use case, activity, state machine, sequence…)। ভয় পাওয়ার কিছু নেই; বাস্তবে বেশিরভাগ দল চার-পাঁচটিই ব্যবহার করে। দুটি কথা মনে রাখুন:

• UML একটি নোটেশন, পদ্ধতি নয়। কোন ক্রমে কোন diagram আঁকবেন, তা UML বলে না। সেটা বলে process — যেমন পর্ব ৪-এ দেখা Unified Process, বা আপনার দলের নিজের নিয়ম।
• Data-flow diagram UML-এর অংশ নয়। এটি আরও পুরোনো structured analysis ধারা থেকে এসেছে (অংশ ৫)। অনেক দল আজও দুটিই ব্যবহার করে।

৩ · Use case diagram — কে, কী লক্ষ্যে, কোন সীমার মধ্যে

পর্ব ২২-এ আপনি লেখা use case দেখেছেন — main success scenario, extension, precondition. Use case diagram সেই লেখার একটি সূচিপত্র: এক পাতায় দেখায় কোন কোন use case আছে আর কে কোনটিতে অংশ নেন। ধাপগুলোর বিস্তারিত diagram-এ থাকে না, থাকে লেখায়। এর উপাদানগুলো:

«include» বনাম «extend» — তীরের দিকই আসল পরীক্ষা

দুটোই ড্যাশ রেখা আর খোলা তীর, তাই গুলিয়ে ফেলা খুব স্বাভাবিক। পার্থক্যটা “কে কাকে জানে” প্রশ্নে:

• «include»: “অর্ডার দেওয়া” use case-এর লেখার ভেতরেই একটি ধাপ আছে — “পেমেন্ট করা use case চালান।” Base জানে included-কে, তাই তীর base থেকে বেরোয়। পেমেন্ট ছাড়া অর্ডার সম্পূর্ণ হয় না। সাধারণত একাধিক use case-এর মধ্যে ভাগ করা অংশ আলাদা করতে এটি ব্যবহার হয় — যেমন “অর্ডার দেওয়া” আর “বকেয়া পরিশোধ” দুটোই পেমেন্ট include করে।
• «extend»: “অর্ডার দেওয়া” নিজে প্রেসক্রিপশনের কথা জানে না; সে শুধু একটি নামের জায়গা খোলা রাখে — extension point “Rx লাগলে”। “প্রেসক্রিপশন আপলোড” নিজেই ঘোষণা করে, “শর্ত [cart-এ Rx-ওষুধ আছে] সত্য হলে আমি ওই জায়গায় যুক্ত হব।” Extension জানে base-কে, তাই তীর extension থেকে বেরোয়। Base নিজে একাই সম্পূর্ণ, অর্থবহ।

Actor-এর generalisation-এ ফাঁপা ত্রিভুজ থাকে সাধারণ actor-এর গায়ে: “গ্রাহক একজন ভিজিটর, সাথে আরও কিছু।” Use case-এর মধ্যেও generalisation আঁকা যায় (যেমন “পেমেন্ট করা”-র দুটি বিশেষ রূপ — mobile wallet আর card), তবে এটি কম ব্যবহৃত, আর অনেক লেখক সাবধানে ব্যবহার করতে বলেন।

এবার একটি ছোট বর্ণনা থেকে ধাপে ধাপে diagram বানাই। বর্ণনা: “ভিজিটর ওষুধ খুঁজতে পারেন। নিবন্ধিত গ্রাহক অর্ডার দেন আর mobile wallet-এ পেমেন্ট করেন; পেমেন্ট হয় একটি বাইরের পেমেন্ট গেটওয়ের মাধ্যমে। কিছু ওষুধের জন্য প্রেসক্রিপশন আপলোড করতে হয়, যা একজন ফার্মাসিস্ট যাচাই করেন।” “পরে” চাপুন।

Use case diagram-এর সাধারণ ভুল

৪ · Domain model — সমস্যার জগতের জিনিসগুলো

Use case বলে মানুষ কী করেন। Domain model বলে সেই কাজে কোন কোন জিনিস জড়িত: গ্রাহক, অর্ডার, ওষুধ, প্রেসক্রিপশন। একে conceptual class model-ও বলা হয়, কারণ প্রতিটি বাক্স একটি conceptual class — বাস্তব জগতের একটি ধারণা, কোডের class নয়। Craig Larman-এর বহুল-পঠিত বই Applying UML and Patterns (প্রথম সংস্করণ ১৯৯৭, তৃতীয় ২০০৪) এই অর্থে শব্দটি জনপ্রিয় করে।

নোটেশন UML class diagram-এর একটি হালকা অংশ:

• বাক্সের ওপরে নাম, নিচে attribute (জিনিসটির বৈশিষ্ট্য: নাম, দাম, অবস্থা)। Method-এর ঘর থাকে না। কে কোন কাজ করবে, সেটা design-এর সিদ্ধান্ত (পর্ব ২৯)।
• দুটি বাক্সের মধ্যে রেখা = association; রেখার দুই প্রান্তে multiplicity — প্রতিটির সাথে অন্যটি কতগুলো থাকতে পারে: 1, 0..1, 0..* (বা *), 1..*.
• Multiplicity পড়ার নিয়ম: যে প্রান্তে সংখ্যা লেখা, সেটা সেই class-এর সংখ্যা। Customer প্রান্তে 1 আর Order প্রান্তে 0..* মানে: “একজন গ্রাহকের শূন্য বা অনেক অর্ডার; প্রতিটি অর্ডার ঠিক একজন গ্রাহকের।”

Noun analysis — বিশেষ্য থেকে class-এর প্রার্থী

Concept কোথা থেকে খুঁজবেন? একটি পুরোনো কৌশল: requirement-এর লেখা থেকে বিশেষ্য (noun) তুলে নিন — সেগুলো class বা attribute-এর প্রার্থী; ক্রিয়া (verb) — use case বা কাজের প্রার্থী। Russell Abbott ১৯৮৩ সালে Communications of the ACM-এ ইংরেজি বর্ণনা থেকে program নকশার এই চিন্তা প্রকাশ করেন বলে সাধারণত উল্লেখ করা হয়; পরে Booch-সহ অনেকে একে জনপ্রিয় করেন। নিচের কোডটি একটি noun analysis-এর খেলনা সংস্করণ — আসল ভাষা-বিশ্লেষণ নয়, শুধু কয়েকটি সহজ নিয়ম: “a/an/the”-এর পরের এক-দুটি শব্দ একটি noun phrase, বাক্যের প্রথম noun phrase কর্তা (actor-এর প্রার্থী), আর ক্রিয়ার তালিকা হাতে দেওয়া।

// Toy noun/verb analysis of a fictional online-pharmacy problem statement.
// Heuristic only: a noun phrase = up to 2 words after "a/an/the";
// verbs come from a small hand-made list; a sentence's first noun phrase
// is its subject (actor candidate); "subject + verb + next noun" = use case.
const text = `A customer searches the catalogue and adds a medicine to the cart.
The customer uploads a prescription for a restricted medicine.
A pharmacist verifies the prescription. The customer places an order
and pays the order by mobile wallet. A rider delivers the order to the
delivery address. The system sends an SMS to the customer.`;
const DET = ["a", "an", "the"], STOP = ["and", "to", "for", "by", "of", "with"];
const VERBS = ["searches", "adds", "uploads", "verifies", "places", "pays", "delivers", "sends"];
const nouns = {}, actors = new Set(), useCases = [];
for (const s of text.toLowerCase().replace(/\n/g, " ").split(".")) {
  const w = s.split(/\s+/).filter(Boolean);
  let subject = null, verb = null;
  for (let i = 0; i < w.length; i++) {
    if (VERBS.includes(w[i])) { verb = w[i]; continue; }
    if (!DET.includes(w[i])) continue;
    const np = [w[i + 1]];                       // the head word after the determiner
    const nx = w[i + 2];
    if (nx && !STOP.includes(nx) && !DET.includes(nx) && !VERBS.includes(nx)) np.push(nx);
    const phrase = np.join(" ");
    nouns[phrase] = (nouns[phrase] || 0) + 1;
    if (!subject) subject = phrase;
    else if (verb) { useCases.push(verb + " " + phrase + "  (" + subject + ")"); verb = null; }
    i += np.length;
  }
  if (subject && subject !== "system") actors.add(subject);
}
console.log("Noun phrases -> candidate classes (count):");
console.log("  " + Object.entries(nouns).sort((a, b) => b[1] - a[1])
  .map(([n, c]) => n + " x" + c).join(", "));
console.log("Actor candidates: " + [...actors].join(", "));
console.log("Use-case candidates (verb + object, actor):");
useCases.forEach(u => console.log("  " + u));

Noun phrases -> candidate classes (count):
  customer x4, order x3, prescription x2, catalogue x1, medicine x1, cart x1, restricted medicine x1, pharmacist x1, rider x1, delivery address x1, system x1, sms x1
Actor candidates: customer, pharmacist, rider
Use-case candidates (verb + object, actor):
  searches catalogue  (customer)
  adds medicine  (customer)
  uploads prescription  (customer)
  verifies prescription  (pharmacist)
  places order  (customer)
  pays order  (customer)
  delivers order  (rider)
  sends sms  (system)

এবার প্রার্থীর তালিকা থেকে মানুষের বিচার দিয়ে domain model বানাই:

৫ · Context diagram আর DFD — data কোথা থেকে কোথায় যায়

Object-oriented model আসার আগে, ১৯৭০-এর দশকে structured analysis ধারা গড়ে ওঠে। এর মূল ছবি data flow diagram (DFD). সাধারণভাবে Tom DeMarco-র Structured Analysis and System Specification (১৯৭৮) আর Edward Yourdon ও Larry Constantine-এর কাজকে এর ভিত্তি ধরা হয়; Chris Gane ও Trish Sarson ১৯৭৯ সালের দিকে একটু ভিন্ন নোটেশন দেন। Yourdon-এর Modern Structured Analysis (১৯৮৯) পরে ধারাটিকে হালনাগাদ করে। DFD-র চারটি উপাদান:

সবচেয়ে ওপরের স্তর context diagram: পুরো system একটিমাত্র process, চারপাশে external entity আর তাদের data flow. কোনো data store থাকে না। এটি system-এর সীমা এক নজরে দেখায় — use case diagram-এর boundary-র মতোই, কিন্তু data-র চোখে।

পরের স্তরে বৃত্তটি “খোলা” হয়: একটি DFD-তে কয়েকটি process, তাদের মধ্যে data flow আর data store. আমাদের উদাহরণে প্রথম ভাঙনটি মোটামুটি এমন:

DFD-র কয়েকটি নিয়ম, যা ভাঙলে ছবিটি ভুল:

• প্রতিটি process-এ অন্তত একটি ঢোকা আর একটি বেরোনো flow. শুধু ঢোকে, বেরোয় না — একে বলে “black hole”; শুধু বেরোয় — “miracle”.
• Data store থেকে data store, বা entity থেকে সরাসরি data store-এ flow নয়। মাঝে একটি process থাকতেই হবে, কারণ data নিজে থেকে চলে না।
• Balancing: একটি process ভাঙলে নিচের স্তরে বাইরে থেকে ঢোকা-বেরোনো flow ওপরের স্তরের সাথে মিলতে হবে। Context diagram-এ গ্রাহক থেকে “অর্ডার, Rx” ঢুকেছে; level 1-এও সেই দুটি flow থাকতে হবে।
• DFD flowchart নয়। এতে সিদ্ধান্তের হীরা (diamond) বা loop নেই। “যদি প্রেসক্রিপশন লাগে” — এটা DFD-র ভাষা নয়।

৬ · Activity diagram — ধারা, সিদ্ধান্ত আর দায়িত্ব

DFD ক্রম দেখায় না; use case diagram-ও না। কাজটি কোন ধাপে, কোন শর্তে, কার হাত ঘুরে এগোয় — এটা দেখাতে activity diagram. দেখতে flowchart-এর মতো, কিন্তু UML ২-তে এর অর্থ token-এর প্রবাহ দিয়ে সংজ্ঞায়িত (Petri net-এর অনুপ্রেরণায়, বলে সাধারণত বলা হয়): একটি token চলতে চলতে action ঘুরে যায়। Requirement-এর স্তরে এটি সবচেয়ে কাজে লাগে একটি ব্যবসার প্রক্রিয়া আঁকতে — যেমন অর্ডার থেকে ডেলিভারি।

Path গোনা — test case পরিকল্পনার শুরু

একটি activity diagram-এর শুরু থেকে শেষ পর্যন্ত যতগুলো আলাদা পথ, প্রতিটি অন্তত একটি acceptance test-এর প্রার্থী। Fork নতুন পথ বানায় না (দুই শাখা সবসময় একসাথে চলে), কিন্তু decision বানায়। নিচের কোডে ছবি ২৩.৪-এর ধারা, সাথে একটি বাস্তব জটিলতা যোগ করা হয়েছে: পেমেন্ট ব্যর্থ হলে আবার চেষ্টা (loop). Loop-কে অসীম পথ বানানো থেকে আটকাতে নিয়ম — প্রতিটি guard-যুক্ত তীর একটি পথে বড়জোর একবার।

// Activity "Place order": count start-to-end paths for test planning.
// Decision edges carry [guards]; each guarded edge is taken at most once
// (so the retry loop runs at most once);
// a fork runs all branches in parallel, so it adds no extra path.
const G = {
  start: ["search"], search: ["addToCart"], addToCart: ["needRx?"],
  "needRx?": [["M", "no"], ["upload", "yes"]],
  upload: ["verify"], verify: ["ok?"],
  "ok?": [["notifyReject", "rejected"], ["M", "approved"]],
  notifyReject: ["endCancelled"],
  M: ["pay"], pay: ["paid?"],                       // M = merge node
  "paid?": [["pay", "failed: retry"], ["fork", "ok"]],
  fork: { parallel: ["pack", "assignRider"], join: "deliver" },
  deliver: ["end"]
};
const paths = [];
function walk(node, path, used) {
  if (node.startsWith("end")) { paths.push(path.concat(node)); return; }
  const out = G[node];
  if (out.parallel) return walk(out.join, path.concat("fork(" + out.parallel.join(" || ") + ")"), used);
  for (const o of out) {
    const [to, guard] = Array.isArray(o) ? o : [o, null];
    const edge = node + ">" + to;
    if (used.has(edge)) continue;                    // each [guard] edge at most once
    const step = guard ? node + "[" + guard + "]" : node;
    walk(to, path.concat(step), guard ? new Set(used).add(edge) : used);
  }
}
walk("start", [], new Set());
paths.forEach((p, i) => console.log("P" + (i + 1) + ": " + p.filter(s => /\[|fork|end/.test(s)).join(" -> ")));
const decisions = Object.values(G).filter(v => Array.isArray(v) && Array.isArray(v[0])).length;
console.log("paths: " + paths.length + ", decision nodes: " + decisions +
  ", basis paths (decisions + 1): " + (decisions + 1));

P1: needRx?[no] -> paid?[failed: retry] -> paid?[ok] -> fork(pack || assignRider) -> end
P2: needRx?[no] -> paid?[ok] -> fork(pack || assignRider) -> end
P3: needRx?[yes] -> ok?[rejected] -> endCancelled
P4: needRx?[yes] -> ok?[approved] -> paid?[failed: retry] -> paid?[ok] -> fork(pack || assignRider) -> end
P5: needRx?[yes] -> ok?[approved] -> paid?[ok] -> fork(pack || assignRider) -> end
paths: 5, decision nodes: 3, basis paths (decisions + 1): 4

৭ · State machine diagram — একটি অর্ডারের জীবনচক্র

Activity diagram একটি প্রক্রিয়া দেখায়, যেখানে অনেক জিনিস জড়িত। State machine diagram দেখায় একটিমাত্র জিনিসের জীবন: সে কোন কোন state-এ থাকতে পারে, আর কোন event-এ, কোন শর্তে এক state থেকে আরেকটিতে যায়। এর ভিত্তি David Harel-এর statecharts (১৯৮৭ সালের প্রবন্ধ), যা তিনি একটি বিমানের avionics system-এর জটিল আচরণ বর্ণনা করতে গিয়ে গড়ে তোলেন বলে নিজে লিখেছেন।

প্রতিটি transition-এর লেবেলের পূর্ণ রূপ: event [guard] / effect.

• Event: যা ঘটে — pay, ship, cancel.
• Guard: বন্ধনীর ভেতরের শর্ত; event এলেও guard মিথ্যা হলে transition হয় না।
• Effect: transition-এর সময় যে কাজ হয় — / refund.

এবার একটি অর্ডারকে event-এর একটি ক্রমের ভেতর দিয়ে চালাই। অর্ডারের দাম ৪৫০ টাকা, প্রেসক্রিপশন লাগে।

একই নিয়ম কোডে একটি transition table হিসেবে লেখা যায়। নিচের প্রোগ্রামে ছবি ২৩.৫-এর প্রতিটি তীর একটি সারি; তিনটি event-ক্রম চালানো হয়েছে:

// Order lifecycle state machine: event [guard] / effect. Unknown event = rejected.
const T = {
  Placed:  { pay:     { to: "Paid", guard: (o, ev) => ev.amount === o.total, why: "amount != total" },
             cancel:  { to: "Cancelled" } },
  Paid:    { verifyRx: { to: "Paid", effect: o => { o.rxOk = true; } },   // internal: state stays
             ship:    { to: "Shipped", guard: o => !o.needsRx || o.rxOk, why: "prescription not verified" },
             cancel:  { to: "Cancelled", effect: o => { o.refund = o.total; } } },
  Shipped: { deliver: { to: "Delivered" } },
  Delivered: {}, Cancelled: {}                                             // final states
};
function run(name, order, events) {
  let s = "Placed";
  console.log("== " + name + " (total " + order.total + ", needsRx " + order.needsRx + ")");
  for (const ev of events) {
    const t = T[s][ev.e];
    if (!t) { console.log("  REJECT " + ev.e + " in " + s + ": no such transition"); continue; }
    if (t.guard && !t.guard(order, ev)) { console.log("  REJECT " + ev.e + " in " + s + ": guard false (" + t.why + ")"); continue; }
    if (t.effect) t.effect(order);
    console.log("  " + s + " --" + ev.e + "--> " + t.to);
    s = t.to;
  }
  console.log("  final: " + s + (order.refund ? ", refund " + order.refund : ""));
}
run("A: happy path", { total: 450, needsRx: true },
  [{ e: "pay", amount: 450 }, { e: "verifyRx" }, { e: "ship" }, { e: "deliver" }]);
run("B: guards stop it", { total: 450, needsRx: true },
  [{ e: "pay", amount: 400 }, { e: "pay", amount: 450 }, { e: "ship" }, { e: "cancel" }]);
run("C: too late to cancel", { total: 120, needsRx: false },
  [{ e: "pay", amount: 120 }, { e: "ship" }, { e: "cancel" }, { e: "deliver" }, { e: "deliver" }]);

== A: happy path (total 450, needsRx true)
  Placed --pay--> Paid
  Paid --verifyRx--> Paid
  Paid --ship--> Shipped
  Shipped --deliver--> Delivered
  final: Delivered
== B: guards stop it (total 450, needsRx true)
  REJECT pay in Placed: guard false (amount != total)
  Placed --pay--> Paid
  REJECT ship in Paid: guard false (prescription not verified)
  Paid --cancel--> Cancelled
  final: Cancelled, refund 450
== C: too late to cancel (total 120, needsRx false)
  Placed --pay--> Paid
  Paid --ship--> Shipped
  REJECT cancel in Shipped: no such transition
  Shipped --deliver--> Delivered
  REJECT deliver in Delivered: no such transition
  final: Delivered

State machine কাগজে না এঁকে লেখা দিয়েও বানানো যায়, যা Git-এ রাখা আর pull request-এ review করা সহজ (পর্ব ১৬)। PlantUML নামের একটি জনপ্রিয় open-source tool-এ ওপরের ছবিটি মোটামুটি এভাবে লেখা হয়:

@startuml
[*] --> Placed
Placed --> Paid : pay [amount = total]
Placed --> Cancelled : cancel
Paid : verifyRx / rxOk := true
Paid --> Shipped : ship [not needsRx or rxOk]
Paid --> Cancelled : cancel / refund
Shipped --> Delivered : deliver
Delivered --> [*]
Cancelled --> [*]
@enduml

Operating systems কোর্সে process-এর state diagram (Process) একই ধারণার আরেকটি পরিচিত উদাহরণ। আর কোডে state machine বানানোর design pattern আসবে পর্ব ৩৬-এ; sequence diagram আর state machine-এর বিস্তারিত (nested state, history) পর্ব ৩০-এ।

৮ · CRUD matrix — model দিয়ে model যাচাই

প্রতিটি model আলাদাভাবে ঠিক দেখাতে পারে, অথচ একসাথে মেলে না। Domain model-এ “Payment” আছে, কিন্তু কোনো use case কি কখনো Payment পড়ে? ওষুধের তালিকা কে তৈরি করে? এই প্রশ্নের একটি পুরোনো আর কার্যকর হাতিয়ার CRUD matrix: সারিতে use case (বা process), কলামে entity, আর প্রতিটি ঘরে সেই use case entity-টিকে কী করে — C (create, তৈরি), R (read, পড়া), U (update, বদলানো), D (delete, মোছা)।

// CRUD matrix: use cases (rows) x entities (columns). C=create R=read U=update D=delete.
const entities = ["Customer", "Medicine", "Prescription", "Order", "Payment", "Delivery"];
const m = {
  "Register":            { Customer: "C" },
  "Search catalogue":    { Medicine: "R" },
  "Upload prescription": { Customer: "R", Prescription: "C" },
  "Verify prescription": { Prescription: "RU" },
  "Place order":         { Customer: "R", Medicine: "R", Prescription: "R", Order: "C" },
  "Pay for order":       { Order: "RU", Payment: "C" },
  "Assign rider":        { Order: "R", Delivery: "C" },
  "Track order":         { Order: "R", Delivery: "R" },
  "Mark delivered":      { Order: "U", Delivery: "U" },
  "Send reminder SMS":   {}
};
const pad = (s, n) => String(s).padEnd(n);
console.log(pad("use case", 20) + entities.map(e => pad(e.slice(0, 5), 6)).join("").trimEnd());
for (const [uc, row] of Object.entries(m))
  console.log(pad(uc, 20) + entities.map(e => pad(row[e] || ".", 6)).join("").trimEnd());
console.log("--- checks ---");
const never = { U: [], D: [] };
for (const e of entities) {
  const ops = Object.values(m).map(r => r[e] || "").join("");
  if (!ops.includes("C")) console.log("PROBLEM " + e + " is never created");
  if (!ops.includes("R")) console.log("PROBLEM " + e + " is never read");
  for (const op of ["U", "D"]) if (!ops.includes(op)) never[op].push(e);
}
console.log("note: never updated: " + never.U.join(", "));
console.log("note: never deleted: " + never.D.join(", "));
for (const [uc, row] of Object.entries(m))
  if (Object.keys(row).length === 0) console.log("PROBLEM use case '" + uc + "' touches no entity");

use case            Custo Medic Presc Order Payme Deliv
Register            C     .     .     .     .     .
Search catalogue    .     R     .     .     .     .
Upload prescription R     .     C     .     .     .
Verify prescription .     .     RU    .     .     .
Place order         R     R     R     C     .     .
Pay for order       .     .     .     RU    C     .
Assign rider        .     .     .     R     .     C
Track order         .     .     .     R     .     R
Mark delivered      .     .     .     U     .     U
Send reminder SMS   .     .     .     .     .     .
--- checks ---
PROBLEM Medicine is never created
PROBLEM Payment is never read
note: never updated: Customer, Medicine, Payment
note: never deleted: Customer, Medicine, Prescription, Order, Payment, Delivery
PROBLEM use case 'Send reminder SMS' touches no entity

CRUD matrix ছাড়াও model-গুলো পরস্পরকে যাচাই করে: use case diagram-এর প্রতিটি use case কি activity diagram-এর কোনো ধারায় আছে? State machine-এর প্রতিটি event কি কোনো use case থেকে আসে? Domain model-এর প্রতিটি class কি context diagram-এর কোনো data flow-এ বা data store-এ দেখা দেয়? এই মিলিয়ে দেখা পর্ব ২৪-এর traceability-র একটি ছোট রূপ।

৯ · Tool আর “just enough” modeling

Model আঁকার tool তিন রকম (নাম আর সুবিধা লেখার সময়ের; সংস্করণ-ভেদে বদলায়):

কতটা model বানাবেন? Waterfall-এর যুগে কিছু project-এ শত শত পাতার model হতো, যা কোড শুরুর আগেই পুরোনো হয়ে যেত। Agile-এর প্রতিক্রিয়ায় Scott Ambler-এর Agile Modeling (২০০২ সালের বই) একটি মধ্যপথ দেয়: model বানান একটি উদ্দেশ্যে, “just barely good enough” পর্যন্ত, আর যা আর কাজে লাগে না তা ফেলে দিতে ভয় পাবেন না। কয়েকটি ব্যবহারিক নিয়ম:

• প্রশ্ন থেকে শুরু করুন। “অর্ডারের বাতিলের নিয়ম পরিষ্কার নয়” — তাহলে শুধু অর্ডারের state machine; পুরো system-এর সব diagram নয়।
• জটিল আর ঝুঁকিপূর্ণ জায়গায় বেশি। টাকা, ওষুধ, আইন — এখানে state machine আর guard সতর্কভাবে। একটি সাধারণ “প্রোফাইল দেখা” page-এর কোনো diagram লাগে না।
• কে রাখবে, ঠিক করুন। যে model কোডের সাথে হালনাগাদ রাখা হবে (যেমন অর্ডারের state machine), সেটি repository-তে text হিসেবে রাখুন; বাকিগুলো আলোচনার পরে ছবি তুলে রেখে দিন, “ঐতিহাসিক” চিহ্ন দিয়ে।
• User story-র পাশে। একটি epic-এর জন্য একটি ছোট activity diagram, বা একটি story-র acceptance criteria-র পাশে একটি state টেবিল প্রায়ই পুরো দলের তর্ক কমায়।

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

এখন একটি requirement-এর লেখা AI-কে দিলেই কয়েক সেকেন্ডে PlantUML বা Mermaid-এর কোড চলে আসে, যা ছবি হয়ে খুব পেশাদার দেখায়। কিন্তু দেখতে ঠিক আর notation-এ ঠিক এক নয়। এই বিষয়ে AI-এর চেনা ভুলগুলো:

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

• Diagram-টি আসলেই render করে দেখেছি; syntax error বা অদৃশ্য উপাদান নেই
• প্রতিটি «include»/«extend»-এর দিক আর অর্থ নিজে যাচাই করেছি
• Domain model-এ method, foreign key বা software-এর অংশ নেই; প্রতিটি multiplicity-র উৎস আছে
• State machine-এর প্রতিটি state × event-এর জন্য উত্তর জানি — transition, guard, নাকি প্রত্যাখ্যান
• “অনুমান” তালিকার প্রতিটি বিষয় stakeholder-কে জিজ্ঞেস করার তালিকায় তুলেছি
• AI-কে পাঠানো লেখা থেকে গোপন তথ্য সরিয়েছি, আর UML-এর সংস্করণ বা বইয়ের উল্লেখ নিজে মিলিয়েছি