UML behaviour diagram — sequence, activity আর state machine diagram

১ · কাঠামোর ছবি থেকে আচরণের ছবিতে

একটি কাল্পনিক অনলাইন চা-পাতার দোকান, নাম “চা-বাগান”। পর্ব ২৯-এ (UML class diagram) দল এর class diagram এঁকেছে: Cart, Order, Payment, Stock — কোন class কার সাথে যুক্ত, কার কাছে কী data. কিন্তু নতুন developer নাদিয়া প্রশ্ন করলেন, “গ্রাহক ‘অর্ডার দিন’ চাপলে প্রথমে কে কাকে ডাকে? টাকা কাটার আগে stock আটকানো হয়, না পরে? পেমেন্ট ব্যর্থ হলে আটকানো stock কি ছেড়ে দেওয়া হয়?” Class diagram এর একটিরও উত্তর দেয় না। সে দেখায় কারা আছে, কে কাকে চেনে; কিন্তু সময়ের সাথে কী ঘটে, তা দেখায় না।

UML ২.৫.১-এ (OMG-র প্রকাশ, ২০১৭ সালের ডিসেম্বর) মোট ১৪ রকম diagram: ৭টি structure diagram আর ৭টি behaviour diagram. Behaviour দলে আছে use case, activity আর state machine diagram, আর তাদের একটি উপদল interaction diagram — sequence, communication, timing আর interaction overview diagram. পর্ব ২৩-এ (Requirement modeling) আপনি activity আর state diagram দেখেছেন requirement-এর স্তরে: ব্যবসার প্রক্রিয়া আর একটি অর্ডারের জীবনচক্র। এই পর্বে একই নোটেশন যাবে design-এর স্তরে — যেখানে বাক্সগুলো আসল object, তীরগুলো আসল method call, আর প্রতিটি নিয়ম কোডে কোথাও বসবে।

একটি সহজ পরীক্ষা মনে রাখুন: diagram-এর উল্লম্ব দিকে সময় থাকলে সেটা sequence; বাক্সগুলো যদি “অবস্থা” হয় (Paid, Shipped), সেটা state machine; বাক্সগুলো যদি “কাজ” হয় (পেমেন্ট নিন, প্যাক করুন), সেটা activity. শেষ অংশে (অংশ ৮) এই বাছাই আরও বিস্তারিত।

২ · Sequence diagram — lifeline, activation আর message

Sequence diagram পড়া হয় ওপর থেকে নিচে: ওপরে সময় শুরু, নিচে শেষ। পাশাপাশি দাঁড়ানো প্রতিটি অংশগ্রহণকারীর নিচে একটি খাড়া ড্যাশ রেখা — lifeline. মাথার বাক্সে লেখা থাকে নাম:Type, যেমন c:Cart, অথবা নাম না জানলে শুধু :Cart (কোলন রেখে)। UML ২-এ মাথার নামের নিচে দাগ (underline) দেওয়া বাধ্যতামূলক নয়; UML ১-এর object-নোটেশন থেকে এই অভ্যাস অনেক বইতে রয়ে গেছে। Lifeline-এর ওপর সরু আয়তক্ষেত্র — activation bar (UML-এর আনুষ্ঠানিক নাম execution specification) — দেখায় object-টি কখন কাজ করছে, অর্থাৎ তার একটি method কখন চলছে।

এর পরে message, আর এখানেই সবচেয়ে বেশি ভুল হয়। UML ২.৫.১ অনুযায়ী তীরের রেখা আর মাথা মিলিয়ে অর্থ:

এবার “চা-বাগান”-এর একটি সহজ অর্ডার ধাপে ধাপে আঁকি। নিচে diagram-এর পাশাপাশি সেই কোডটিও আছে, যা এই message-গুলো তৈরি করে — প্রতিটি ধাপে কোন লাইন কোন তীর বানাল, তা মিলিয়ে দেখুন।

1class OrderService {2  placeOrder(cart) {3    this.validate(cart);4    if (!this.inventory.reserve(cart.items))5      throw new Error("out of stock");6    const order = new Order(cart);7    return order.id;          // "ORD-31"8  }9}

এক সাধারণ প্রশ্ন: কোন object-গুলো diagram-এ রাখবেন? নিয়ম — শুধু সেগুলো, যারা এই scenario-র প্রশ্নের উত্তরে লাগে। Logging, getter-setter বা প্রতিটি utility call আঁকলে diagram একটি অপঠনীয় ঘন জাল হয়ে যায়। একটি diagram-এ পাঁচ-ছয়টির বেশি lifeline আর পনেরো-বিশটির বেশি message দেখলে ভাবুন, ভাগ করা যায় কি না (ref, অংশ ৩)।

৩ · Combined fragment — alt, opt, loop, par, break আর ref

বাস্তব কোডে if আছে, loop আছে, ব্যর্থতা আছে। Sequence diagram-এ এগুলো দেখানো হয় combined fragment দিয়ে: কয়েকটি message ঘিরে একটি আয়তক্ষেত্র, বাঁ-ওপরের কোণে একটি পাঁচকোনা লেবেলে interaction operator-এর নাম। আয়তক্ষেত্রটি ড্যাশ রেখায় এক বা একাধিক operand-এ ভাগ হতে পারে, আর প্রতিটি operand-এর শুরুতে বন্ধনীতে একটি guard: [paid].

UML ২.৫.১-এ মোট ১২টি interaction operator: ওপরের পাঁচটির সাথে seq, strict, neg (এই ক্রম ঘটা নিষেধ), critical (মাঝখানে অন্য কিছু ঢুকতে পারবে না), ignore, consider আর assert. বাস্তবে প্রায় সব diagram-এ প্রথম পাঁচটি আর ref-ই যথেষ্ট। নিচের ছবিতে “চা-বাগান”-এর checkout: প্রতিটি item-এর জন্য stock আটকানো (loop), তারপর টাকা কাটা, আর ফল অনুযায়ী দুই পথ (alt).

Guard নিয়ে দুটি নিয়ম মনে রাখুন। প্রথম, guard লেখা হয় সেই lifeline-এর ওপরে, যার data দিয়ে শর্তটি যাচাই হয় — এখানে Cart জানে পেমেন্টের ফল। দ্বিতীয়, alt-এর guard-গুলো পরস্পর-বর্জিত আর সম্পূর্ণ হওয়া উচিত; [amount > 500] আর [amount < 1000] একসাথে সত্য হতে পারে, তাতে কোনটি চলবে তা অস্পষ্ট। নিশ্চিত হতে শেষ operand-এ [else] রাখুন।

par আর ref-এর একটি ছোট উদাহরণ লেখায়: অর্ডার নিশ্চিত হলে SMS আর email একসাথে যায় — par fragment, দুই operand. আর লগইনের পুরো আদান-প্রদান যদি আলাদা diagram “Authenticate”-এ আঁকা থাকে, checkout diagram-এর শুরুতে শুধু একটি ref বাক্স: ref Authenticate. এতে একটি diagram ছোট থাকে, আর লগইনের নিয়ম বদলালে এক জায়গায় বদলাতে হয় — কোডে function বের করে আনার মতোই।

Fragment থেকে test scenario

প্রতিটি combined fragment একটি করে সিদ্ধান্ত। সবগুলো মিলিয়ে diagram-এর শুরু থেকে শেষ পর্যন্ত যতগুলো আলাদা পথ, প্রতিটি একটি test scenario-র প্রার্থী। Loop অসীম পথ বানাতে পারে, তাই একটি সীমা ধরে নিতে হয় — এখানে item ১ বা ২টি। নিচের কোডটি fragment-এর একটি ছোট গাছ থেকে সব পথ গুনে বের করে:

// From combined fragments (loop, opt, alt) to test scenarios: enumerate every path.
const M = s => ({ k: "msg", s });
const checkout = [
  M("Customer->Cart: checkout()"),
  { k: "loop", min: 1, max: 2, guard: "items", body: [M("Cart->Stock: reserve(item)")] },
  { k: "opt", guard: "coupon", body: [M("Cart->Promo: apply(code)")] },
  M("Cart->Pay: charge(total)"),
  { k: "alt", ops: [
    { guard: "paid",     body: [M("Pay-->Cart: ok"), M("Cart-->Customer: receipt")] },
    { guard: "declined", body: [M("Pay-->Cart: declined"), M("Cart-->Customer: error")] } ] }
];
const join = (a, b) => ({ g: [...a.g, ...b.g], m: [...a.m, ...b.m] });
function paths(frags) {                       // all paths through a sequence of fragments
  let acc = [{ g: [], m: [] }];
  for (const f of frags) { const alts = expand(f); acc = acc.flatMap(a => alts.map(o => join(a, o))); }
  return acc;
}
function expand(f) {                          // the alternatives one fragment offers
  const tag = (g, ps) => ps.map(p => join({ g: [g], m: [] }, p));
  if (f.k === "msg") return [{ g: [], m: [f.s] }];
  if (f.k === "opt") return [{ g: ["no " + f.guard], m: [] }, ...tag(f.guard, paths(f.body))];
  if (f.k === "alt") return f.ops.flatMap(op => tag(op.guard, paths(op.body)));
  const out = [];                             // loop(min, max): unroll n = min..max times
  for (let n = f.min; n <= f.max; n++)
    out.push(...tag(f.guard + "=" + n, paths(Array(n).fill(f.body).flat())));
  return out;
}
const all = paths(checkout);
all.forEach((p, i) => console.log("S" + (i + 1) + " [" + p.g.join(", ") + "] " + p.m.length + " msgs"));
console.log("total " + all.length + " = loop 2 x opt 2 x alt 2");
console.log("S8 messages:\n  " + all[7].m.join("\n  "));

S1 [items=1, no coupon, paid] 5 msgs
S2 [items=1, no coupon, declined] 5 msgs
S3 [items=1, coupon, paid] 6 msgs
S4 [items=1, coupon, declined] 6 msgs
S5 [items=2, no coupon, paid] 6 msgs
S6 [items=2, no coupon, declined] 6 msgs
S7 [items=2, coupon, paid] 7 msgs
S8 [items=2, coupon, declined] 7 msgs
total 8 = loop 2 x opt 2 x alt 2
S8 messages:
  Customer->Cart: checkout()
  Cart->Stock: reserve(item)
  Cart->Stock: reserve(item)
  Cart->Promo: apply(code)
  Cart->Pay: charge(total)
  Pay-->Cart: declined
  Cart-->Customer: error

৪ · Diagram থেকে কোড, কোড থেকে diagram

Design-স্তরের sequence diagram-এর আসল শক্তি হলো, এর প্রায় প্রতিটি চিহ্নের একটি নির্দিষ্ট কোড-রূপ আছে। তাই diagram দেখে কোড review করা যায়, আর কোড দেখে diagram যাচাই করা যায়।

এই মিল থেকে design-এর গুণও পড়া যায়। একটি lifeline থেকে যদি প্রায় সব lifeline-এ তীর যায়, ওই class সম্ভবত বেশি কিছু জানে আর বেশি কিছুর ওপর নির্ভর করে — পর্ব ২৫-এর (Modularity, coupling আর cohesion) ভাষায় উঁচু coupling. আর তীরের লম্বা শিকল (A ডাকে B-কে, B-র কাছ থেকে পাওয়া C-কে, C-র কাছ থেকে পাওয়া D-কে) হলো সেই কাঠামো, যার বিরুদ্ধে Law of Demeter সতর্ক করে — পর্ব ২৬ (নকশার নীতি)। প্রতিটি synchronous message আসলে একটি interface-এর method; তার আগে-পরের শর্ত (precondition, postcondition) কীভাবে লিখবেন, তা পর্ব ৩১-এ (Interface আর contract).

চালানো কোড থেকে sequence diagram

উল্টো দিকও সম্ভব, আর অচেনা কোডবেস বুঝতে খুব কাজের: কোডটি চালান, প্রতিটি call রেকর্ড করুন, তারপর রেকর্ড থেকে diagram বানান। নিচের প্রোগ্রাম তিনটি class-এর প্রতিটি method-কে একটি “মোড়ক” (wrapper) দিয়ে ঢেকে দেয়। মোড়কটি একটি stack রাখে — কে এখন ডাকছে — আর প্রতিটি call ও return-কে PlantUML-এর মতো এক লাইনে লেখে।

// Record a real call trace and print it as PlantUML-like sequence text.
let trace = [], stack = ["Customer"];             // stack top = who is calling now
function instrument(name, obj) {
  const proto = Object.getPrototypeOf(obj);
  for (const m of Object.getOwnPropertyNames(proto)) {
    if (m === "constructor") continue;
    obj[m] = function (...args) {                 // wrapper: log call, run, log return
      const caller = stack[stack.length - 1];
      trace.push(caller + " -> " + name + " : " + m + "(" + args.join(", ") + ")");
      stack.push(name);
      const r = proto[m].apply(this, args);
      stack.pop();
      trace.push(name + " --> " + caller + " : " + r);
      return r;
    };
  }
  return obj;
}
class Stock   { reserve(sku, qty) { return qty <= 5; } }
class Payment { charge(amount) { return amount <= 2000 ? "ok" : "declined"; } }
class Checkout {
  constructor(stock, pay) { this.stock = stock; this.pay = pay; }
  placeOrder(sku, qty, price) {
    if (!this.stock.reserve(sku, qty)) return "out-of-stock";
    const total = this.total(qty, price);         // self-call
    return this.pay.charge(total) === "ok" ? "ORD-7" : "payment-failed";
  }
  total(qty, price) { return qty * price; }
}
const co = instrument("Checkout",
  new Checkout(instrument("Stock", new Stock()), instrument("Payment", new Payment())));
for (const [qty, price] of [[2, 350], [3, 900]]) {
  trace = []; co.placeOrder("tea", qty, price);
  console.log("@startuml\n" + trace.join("\n") + "\n@enduml");
}

@startuml
Customer -> Checkout : placeOrder(tea, 2, 350)
Checkout -> Stock : reserve(tea, 2)
Stock --> Checkout : true
Checkout -> Checkout : total(2, 350)
Checkout --> Checkout : 700
Checkout -> Payment : charge(700)
Payment --> Checkout : ok
Checkout --> Customer : ORD-7
@enduml
@startuml
Customer -> Checkout : placeOrder(tea, 3, 900)
Checkout -> Stock : reserve(tea, 3)
Stock --> Checkout : true
Checkout -> Checkout : total(3, 900)
Checkout --> Checkout : 2700
Checkout -> Payment : charge(2700)
Payment --> Checkout : declined
Checkout --> Customer : payment-failed
@enduml

পেশাদার জগতে একই চিন্তা বড় আকারে: কিছু IDE আর static analysis tool কোড পড়ে sequence diagram আঁকতে পারে, আর অনেকগুলো service-এর system-এ distributed tracing (যেমন OpenTelemetry মানদণ্ডে) প্রতিটি request-এর span রেকর্ড করে, যা দেখতে প্রায় sequence বা timing diagram-এর মতো। বিস্তারিত System Design কোর্সের Observability পর্বে।

Communication আর timing diagram — সংক্ষেপে

Communication diagram (UML ১-এ নাম ছিল collaboration diagram) একই আদান-প্রদান দেখায়, কিন্তু সময়-রেখা ছাড়া: object-গুলো মুক্তভাবে ছড়ানো, যোগাযোগের রেখার পাশে নম্বর দেওয়া message — 1: checkout(), 1.1: reserve(item), 1.2: charge(total). দশমিক নম্বর nesting বোঝায়: ১.১ হলো ১-এর ভেতর থেকে ডাকা। কে কার সাথে যুক্ত, তা এক নজরে বোঝা যায়; কিন্তু ক্রম পড়তে নম্বর খুঁজতে হয়, আর fragment আঁকা যায় না। Sequence আর communication diagram একই তথ্যের দুই রূপ, তাই অনেক tool একটি থেকে অন্যটি বানাতে পারে। Timing diagram এক লাইনে: আড়াআড়ি অক্ষে সময়, আর প্রতিটি lifeline-এর state কখন বদলায় তা ধাপ-আকৃতির রেখায় — embedded আর real-time system-এ, যেখানে “৫০ ms-এর মধ্যে” ধরনের শর্ত জরুরি।

৫ · State machine — entry, exit, do আর তিন রকম transition

পর্ব ২৩-এ state, transition আর event [guard] / effect লেবেল দেখেছেন। Design-স্তরে একটি state শুধু নাম নয়; তার ভেতরে কাজও থাকে। State-এর বাক্সে নামের নিচে আরেকটি ঘর (compartment) রাখা যায়:

• entry / কাজ — state-এ ঢোকার সময় প্রতিবার একবার চলে, যে তীর দিয়েই ঢুকুন। উদাহরণ: Buffering-এ ঢুকলেই spinner দেখানো।
• exit / কাজ — বেরোনোর সময় প্রতিবার একবার, যে তীর দিয়েই বেরোন। উদাহরণ: spinner লুকানো।
• do / কাজ — entry শেষ হলে শুরু হয়, state-এ থাকা অবস্থায় চলতে থাকে; শেষ হওয়ার আগে state ছাড়তে হলে মাঝপথে থামিয়ে দেওয়া হয়। উদাহরণ: do / downloadChunk. Do শেষ হলে একটি completion event তৈরি হয়, আর লেবেলবিহীন তীর সেটার জন্যই অপেক্ষা করে।

এখানেই entry আর effect-এর তফাত: effect একটি নির্দিষ্ট তীরের কাজ, entry একটি state-এর. কোনো state-এ পাঁচটি তীর ঢুকলে আর পাঁচটির effect-এ একই কাজ লেখা থাকলে, সেটা entry-তে সরিয়ে দিন — কোডে duplicate কমানোর মতোই।

একটি তীর চললে কাজের ক্রম UML-এ নির্দিষ্ট: উৎস state-এর exit → transition-এর effect → লক্ষ্য state-এর entry. তারপর লক্ষ্যে do শুরু। আরেকটি মৌলিক নিয়ম run-to-completion: state machine একবারে একটি event নেয়, আর তার সব কাজ (exit, effect, entry) শেষ হলে তবেই পরের event. মাঝখানে আসা event queue-তে অপেক্ষা করে। এজন্যই entry বা effect-এ দীর্ঘ কাজ (নেটওয়ার্ক call) রাখা বিপজ্জনক — পুরো machine আটকে যায়; সেসব do-তে বা আলাদা asynchronous কাজে রাখুন।

Choice আর junction — দুটি সিদ্ধান্ত-বিন্দু

একটি তীর মাঝপথে ভাগ হতে পারে, শর্ত অনুযায়ী। UML-এ এর দুটি pseudostate (আসল state নয়, পথের একটি বিন্দু):

তফাতটি একটি উদাহরণে: Cart-এর submit / total := computeTotal() তীরের পরে একটি সিদ্ধান্ত — [total > 5000] হলে NeedsApproval, [else] হলে AwaitingPayment. Choice হলে guard নতুন হিসাব করা total দেখবে। Junction হলে guard যাচাই হবে effect চলার আগে, অর্থাৎ পুরোনো total দিয়ে — এক সূক্ষ্ম bug, যা diagram-এ একটি বৃত্ত বনাম হীরার তফাত মাত্র।

State table — একই machine, সারণিতে

State machine-কে সারণিতেও লেখা যায়: সারিতে state, কলামে event, ঘরে “পরের state / effect”. ছবিতে যা চোখ এড়ায়, সারণিতে তা ধরা পড়ে — প্রতিটি ঘর আপনাকে জিজ্ঞেস করে, “এই অবস্থায় এই event এলে কী হবে?” ফাঁকা ঘর মানে হয় ইচ্ছাকৃত উপেক্ষা, নয়তো ভুলে যাওয়া requirement. নিচে পরের অংশের মিডিয়া প্লেয়ারের state table (একটি কাল্পনিক অনলাইন অডিও-বই অ্যাপ):

“—” মানে event উপেক্ষিত। তারকা (*) চিহ্নিত ঘরগুলো আসলে একটিই তীর — composite Playing-এর সীমা থেকে বেরোনো — যা দুই substate-ই উত্তরাধিকারে পায়। সারণিতে তা দুবার লিখতে হলো; ছবিতে একবার আঁকলেই চলে। এটাই composite state-এর সুবিধা, যা এখন দেখব। State table-এর প্রতিটি ঘর একটি test case-এর প্রার্থী; test case নকশার কৌশলগুলো আসবে পর্ব ৪৭-এ।

৬ · Composite state, history আর orthogonal region

১৯৮৭ সালে David Harel তাঁর statecharts প্রবন্ধে সাধারণ state diagram-এর একটি বড় সমস্যা দেখান: জটিল system-এ state-এর সংখ্যা বিস্ফোরিত হয়, আর একই তীর বহু জায়গায় আঁকতে হয়। তাঁর সমাধান, যা পরে UML-এ এসেছে, তিনটি: state-এর ভেতরে state (nesting), history, আর একসাথে চলা অংশ (orthogonality).

• Composite state: একটি state, যার ভেতরে নিজস্ব ছোট state machine — substate-গুলো। ভেতরে থাকা মানে বাইরেরটিতেও থাকা: Buffering-এ থাকলে প্লেয়ার একই সাথে Playing-এও। Composite-এর সীমা থেকে বেরোনো একটি তীর (pause) ভেতরের সব substate-এর জন্য প্রযোজ্য।
• Shallow history (বৃত্তে H): Composite থেকে বেরিয়ে আবার H-এর দিকে ফিরলে, ঠিক যে substate-এ ছিলেন সেখানে ফেরেন — তবে শুধু এক স্তর; সেই substate নিজে composite হলে তার ভেতরে যায় তার initial state-এ। আগে কখনো ঢোকা না হলে H-এর নিজের default তীর, তা না থাকলে composite-এর initial state.
• Deep history (H*): সব স্তর মনে রাখে — একদম ভেতরের state পর্যন্ত আগের মতো ফেরায়।
• Orthogonal region: একটি composite state ড্যাশ রেখায় কয়েকটি region-এ ভাগ, প্রতিটি region-এ একটি করে substate একসাথে সক্রিয়। যেমন Playing-এর ভেতরে এক region-এ Normal/Buffering, আরেক region-এ Muted/Audible.

এবার এই machine-কে কয়েকটি event দিয়ে চালাই, আর প্রতিটি event-এ কোন exit, কোন effect, কোন entry কোন ক্রমে চলে, তা দেখি। সবচেয়ে বেশি নজর দিন শেষ সারিতে — history কখন বদলায়।

একই নিয়ম একটি ছোট runner-এ। প্রতিটি state-এর parent জানা আছে; একটি event এলে কোড সবচেয়ে ভেতরের যে state ওই event সামলায় সেটা খোঁজে, উৎস আর লক্ষ্যের সাধারণ পূর্বপুরুষ (common ancestor) পর্যন্ত exit করে, effect চালায়, তারপর লক্ষ্য পর্যন্ত entry করে।

// Hierarchical state machine: entry/exit order, effects and a shallow history (H).
const PARENT = { Idle: null, Playing: null, Paused: null, Normal: "Playing", Buffering: "Playing" };
const INITIAL = { Playing: "Normal" };              // default substate of the composite
const T = {                                         // "source:event" -> [target, effect]
  "Idle:play": ["Playing", "openStream"],   "Normal:stall": ["Buffering", ""],
  "Buffering:ready": ["Normal", ""],        "Playing:pause": ["Paused", "saveTime"],
  "Paused:resume": ["Playing.H", "seek"],   "Playing:stop": ["Idle", "close"],
  "Paused:stop": ["Idle", "close"]
};
const history = {};                                 // composite -> last active child
const path = s => (s ? [...path(PARENT[s]), s] : []); // [outermost, ..., s]
let leaf = "Idle";
function fire(ev) {
  let src = leaf;
  while (src && !T[src + ":" + ev]) src = PARENT[src]; // innermost state that handles ev
  if (!src) return console.log(ev.padEnd(7) + "ignored in " + leaf);
  const [spec, effect] = T[src + ":" + ev], [tgt, viaH] = spec.split(".");
  const from = path(leaf), to = path(tgt), out = [];
  let k = 0;                                        // length of the common, untouched prefix
  while (k < from.length && k < to.length && from[k] === to[k] && from[k] !== src) k++;
  for (let i = from.length - 1; i >= k; i--) {      // exit: innermost first
    if (i + 1 < from.length) history[from[i]] = from[i + 1];
    out.push("exit " + from[i]);
  }
  if (effect) out.push("/" + effect);               // effect runs between exits and entries
  for (let i = k; i < to.length; i++) out.push("entry " + to[i]); // entry: outermost first
  let s = tgt, child = (viaH && history[tgt]) || INITIAL[tgt];
  while (child) { out.push("entry " + child); s = child; child = INITIAL[child]; }
  leaf = s;
  console.log(ev.padEnd(7) + out.join(", ") + "  => " + path(leaf).join("."));
}
["play", "stall", "pause", "ready", "resume", "ready", "pause", "resume", "stop"].forEach(fire);

play   exit Idle, /openStream, entry Playing, entry Normal  => Playing.Normal
stall  exit Normal, entry Buffering  => Playing.Buffering
pause  exit Buffering, exit Playing, /saveTime, entry Paused  => Paused
ready  ignored in Paused
resume exit Paused, /seek, entry Playing, entry Buffering  => Playing.Buffering
ready  exit Buffering, entry Normal  => Playing.Normal
pause  exit Normal, exit Playing, /saveTime, entry Paused  => Paused
resume exit Paused, /seek, entry Playing, entry Normal  => Playing.Normal
stop   exit Normal, exit Playing, /close, entry Idle  => Idle

Orthogonal region আর state-বিস্ফোরণ

ধরুন প্লেয়ারের তিনটি স্বাধীন দিক: playback (Normal/Buffering — ২টি), গুণমান (Low/Medium/High — ৩টি), আর শব্দ (Muted/Audible — ২টি)। Region ছাড়া একটি সমতল machine-এ প্রতিটি সম্ভাব্য মিশ্রণ আলাদা state: ২ × ৩ × ২ = ১২টি state, আর “mute” তীর আঁকতে হবে ৬ জোড়া state-এর মধ্যে। তিনটি orthogonal region দিলে state লাগে ২ + ৩ + ২ = ৭টি, আর প্রতিটি region নিজের তীর নিজে রাখে। সাধারণভাবে k-টি করে state-এর n-টি স্বাধীন দিক থাকলে সমতলে kⁿ, region-এ k·n. স্বাধীন দিক যত বাড়ে, পার্থক্য তত সূচকীয় হারে বাড়ে — Harel ঠিক এই state explosion-এর সমাধান খুঁজছিলেন।

লেখার আকারে, PlantUML-এর নথি অনুযায়ী ছবি ৩০.২ মোটামুটি এভাবে লেখা যায় (Playing[H] মানে Playing-এর shallow history; deep হলে [H*]):

উদাহরণ · player.puml

@startuml
[*] --> Idle
Idle --> Playing : play / openStream
state Playing {
  [*] --> Normal
  Normal --> Buffering : stall
  Buffering --> Normal : ready
}
Playing : entry / startClock
Playing : exit / stopClock
Buffering : entry / spin
Buffering : exit / unspin
Playing --> Paused : pause / saveTime
Paused --> Playing[H] : resume / seek
Playing --> Idle : stop / close
@enduml

PlantUML-এ composite-এর ভেতরে -- লিখে region ভাগ করা যায়। Mermaid-এর stateDiagram-v2-তে composite আর region (--) আছে, কিন্তু লেখার সময়ে history pseudostate-এর আলাদা চিহ্ন নেই বলেই আমাদের জানা — তাই history-নির্ভর নকশা Mermaid-এ আঁকলে একটি note দিয়ে বুঝিয়ে দিন। দুটি tool-এর নিয়মই version-ভেদে বদলায়; নিজের version-এ render করে মিলিয়ে নিন।

৭ · Design-স্তরের activity diagram — object flow, pin আর token

পর্ব ২৩-এর activity diagram ছিল ব্যবসার প্রক্রিয়া: কোন ধাপ কার দায়িত্ব। Design-স্তরে একই ছবি একটি algorithm বা workflow-এর ভেতর দেখায়, আর তখন দুটি জিনিস জরুরি হয়ে ওঠে — data কোথা থেকে কোথায় যায়, আর সমান্তরাল অংশগুলো ঠিক কীভাবে মেলে। UML ২-এ activity-র অর্থ token দিয়ে সংজ্ঞায়িত: একটি action চলে তখনই, যখন তার প্রতিটি আগত তীরে token অপেক্ষা করছে; শেষ হলে প্রতিটি বহির্গামী তীরে token দেয়।

• Control flow বনাম object flow: সাধারণ তীর শুধু “এরপর এটা” বোঝায় (control token). Object flow-এর তীর একটি data বহন করে (object token) — যেমন একটি Order object.
• Object node: আয়তক্ষেত্র, ভেতরে type: Order, প্রয়োজনে অবস্থাসহ Order [paid]. দুটি action-এর মাঝে data কোথায় অপেক্ষা করে, তা দেখায়।
• Pin: Action-এর গায়ে লাগানো ছোট বর্গ, পাশে নাম ও type — বাঁয়ে input pin (cart: Cart), ডানে output pin (order: Order). Pin হলো action-এর parameter আর return value; কোডে function signature-এর সরাসরি ছবি।
• Decision বনাম merge: দুটিই হীরা। Decision-এ এক তীর ঢোকে, কয়েকটি guard-যুক্ত তীর বেরোয়, token যায় একটিতে। Merge-এ কয়েকটি তীর ঢোকে, একটি বেরোয়, আর যে token আসে তা অপেক্ষা না করে চলে যায়।
• Fork আর join: Fork একটি token নিয়ে প্রতিটি বহির্গামী তীরে একটি করে কপি দেয়। Join প্রতিটি আগত তীরে token-এর অপেক্ষা করে, সব এলে সেগুলো নিয়ে একটি token ছাড়ে।
• Activity final বনাম flow final: Activity final (বৃত্তের ভেতরে ভরাট বৃত্ত)-এ একটি token পৌঁছালেই পুরো activity শেষ, অন্য সব token মুছে যায়। Flow final (বৃত্তে ×) শুধু সেই একটি token-কে শেষ করে।
• Interruptible region: ড্যাশ রেখার গোল কোণের আয়তক্ষেত্র। ভেতরের একটি accept-event action (যেমন “গ্রাহক বাতিল করলেন”) থেকে বিদ্যুৎ-চমক আকৃতির (zigzag) তীর বাইরে গেলে, সেই মুহূর্তে region-এর ভেতরের সব token মুছে যায় — প্যাকিং আর পেমেন্ট দুটোই থেমে যায়, ধারা যায় “refund”-এ।

নিচে “চা-বাগান”-এর অর্ডার প্রক্রিয়ার একটি অংশ: fork-এর পরে টাকা কাটা (২ tick সময় লাগে) আর প্যাক করা (৩ tick) একসাথে, join-এর পরে পাঠানো (১ tick). কমলা বিন্দুগুলো token.

# Token game: a join waits for a token on EVERY incoming edge; a merge does not.
from collections import Counter

DUR = {"charge": 2, "pack": 3, "ship": 1}        # ticks each action takes
IN = {"charge": "f1", "pack": "f2", "ship": "g"}  # incoming edge of each action
OUT = {"charge": "c", "pack": "p", "ship": "end"}

def run(gate):
    print(f"== gate before ship is a {gate}")
    tok, busy = Counter(start=1), {}
    for t in range(1, 7):
        ev = []
        for a in list(busy):                       # running actions tick down
            busy[a] -= 1
            if busy[a] == 0:
                del busy[a]; tok[OUT[a]] += 1; ev.append(a + " done")
        if tok["start"]:                           # fork: 1 token in, 1 copy per out-edge
            tok["start"] -= 1; tok["f1"] += 1; tok["f2"] += 1; ev.append("fork 1->2")
        if gate == "join":
            while tok["c"] and tok["p"]:           # needs both, consumes both, emits one
                tok["c"] -= 1; tok["p"] -= 1; tok["g"] += 1; ev.append("join fires")
        else:
            for e in ("c", "p"):                   # merge passes every token on its own
                while tok[e]:
                    tok[e] -= 1; tok["g"] += 1; ev.append("merge passes " + e)
        for a in DUR:                              # an action starts when its token waits
            if tok[IN[a]] and a not in busy:
                tok[IN[a]] -= 1; busy[a] = DUR[a]; ev.append("start " + a)
        wait = {e: tok[e] for e in ("c", "p") if tok[e]}
        print(f"t={t}: {', '.join(ev) or '-'} | waiting at gate {wait}")
    print(f"ship ran {tok['end']} time(s)\n")

run("join")
run("merge")

== gate before ship is a join
t=1: fork 1->2, start charge, start pack | waiting at gate {}
t=2: - | waiting at gate {}
t=3: charge done | waiting at gate {'c': 1}
t=4: pack done, join fires, start ship | waiting at gate {}
t=5: ship done | waiting at gate {}
t=6: - | waiting at gate {}
ship ran 1 time(s)

== gate before ship is a merge
t=1: fork 1->2, start charge, start pack | waiting at gate {}
t=2: - | waiting at gate {}
t=3: charge done, merge passes c, start ship | waiting at gate {}
t=4: pack done, ship done, merge passes p, start ship | waiting at gate {}
t=5: ship done | waiting at gate {}
t=6: - | waiting at gate {}
ship ran 2 time(s)

সমান্তরাল কাজের এই সমস্যাগুলো কোডেও একই রূপে আসে: Promise.all হলো join, আর দুটি callback-এর যেকোনো একটিতে “পরের ধাপ” ডাকা হলো merge-এর ভুল। Thread আর synchronization-এর দিকটি বিস্তারিত দেখতে Operating Systems কোর্সের Thread পর্ব।

৮ · কোন প্রশ্নে কোন diagram — আর diagram-কে লেখায় রাখা

সব diagram আঁকার দরকার নেই, দরকার সঠিকটি। শুরু করুন প্রশ্ন দিয়ে, diagram দিয়ে নয়:

একটি সাধারণ ভুল হলো state machine-এ কাজের ধাপকে state বানানো: “ValidateCart”, “ChargeCard”, “SendEmail” — এগুলো activity-র action. State-এর নাম সাধারণত বিশেষণ বা অবস্থা: Pending, Paid, Buffering; সেখানে object কিছুক্ষণ থাকে আর event-এর অপেক্ষা করে।

Diagram as code — Git-এ রাখার মতো

ছবির ফাইল (PNG) Git-এ রাখলে diff পড়া যায় না, review-ও কঠিন। তাই অনেক দল diagram লেখে লেখার আকারে — diagram as code — আর tool সেটা থেকে ছবি বানায়। সবচেয়ে প্রচলিত দুটি open-source tool PlantUML আর Mermaid. লেখার সময়ে GitHub আর GitLab-সহ কয়েকটি platform Markdown-এর ভেতরের Mermaid block সরাসরি ছবি করে দেখায়; platform-ভেদে সমর্থন আলাদা। তাতে design বদলালে pull request-এ লাইন-ধরে পরিবর্তন দেখা যায় (পর্ব ১৬, Pull request আর fork). ছবি ৩০.১-এর diagram Mermaid-এ (Mermaid ১১.৪.১-এ render করে যাচাই করা):

উদাহরণ · checkout.mmd

sequenceDiagram
    actor U as Customer
    participant C as Cart
    participant S as Stock
    participant P as Payment
    U->>C: checkout()
    activate C
    loop for each item
        C->>S: reserve(item)
        S-->>C: ok
    end
    C->>P: charge(total)
    activate P
    alt paid
        P-->>C: ok
        C-)S: commit()
        C-->>U: receipt
    else declined
        P-->>C: declined
        C-->>U: error
    end
    deactivate P
    deactivate C

সাবধান, দুই tool-এর চিহ্ন এক নয়। Mermaid-এ ->> হলো ভরাট মাথার সরল রেখা (synchronous), -->> ড্যাশ reply, আর -) খোলা মাথার asynchronous. PlantUML-এ -> synchronous, --> ড্যাশ, আর ->> সরু খোলা মাথা — অর্থাৎ PlantUML-এর ->> আর Mermaid-এর ->> দুই ভিন্ন অর্থের তীর। এক tool-এর অভ্যাসে অন্যটিতে লিখলে diagram চুপচাপ ভুল কথা বলবে। প্রতিটি tool-এর বর্তমান নথি দেখে নিন; আর এখানে দেওয়া PlantUML লেখাগুলো তাদের নথির নিয়ম মেনে লেখা, কিন্তু এই পাতার জন্য render করে যাচাই করা হয়নি — নিজের version-এ একবার চালিয়ে দেখুন।

৯ · AI-এর যুগে — AI-এর আঁকা behaviour diagram যাচাই

AI এক মুহূর্তে PlantUML বা Mermaid লিখে দেয়, আর render করলে ছবিটি দেখতে নিখুঁত লাগে। বিপদটা সেখানেই: বিশ্বাসযোগ্য দেখায়, কিন্তু ভুল. Behaviour diagram-এ AI-এর পরিচিত ভুলগুলো:

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

• নিজের tool-এ render করেছি, কোনো error বা সতর্কবার্তা নেই
• প্রতিটি message-এর জন্য কোডের লাইন খুঁজে পেয়েছি, আর কোডের প্রতিটি শাখা কোনো fragment-এ আছে
• তীরের মাথা আর রেখা (ভরাট/খোলা, সরল/ড্যাশ) প্রতিটি আলাদা করে মিলিয়েছি
• State machine-এ প্রতিটি state × event ঘর একটি state table-এ ভরেছি, আর ফাঁকা ঘরগুলো ইচ্ছাকৃত কি না ভেবেছি
• Activity-তে fork-join আর decision-merge জোড়া মিলিয়েছি, অন্তত একটি পথে token হাতে চালিয়েছি
• কোড বা diagram কোনো গোপন তথ্য (API key, গ্রাহকের data) AI-কে পাঠানোর আগে মুছে দিয়েছি