Davranışsal modelleme 2: state machine ve activity diyagramları

İlk sayfada nesnelerin birbirleriyle nasıl mesajlaştığını gördün. Bu sayfada iki farklı bakış var. State machine diagram tek bir nesnenin yaşamı boyunca geçtiği durumları gösterir: bir kitap kopyası rafta, ayrılmış, ödünçte, gecikmiş, kayıp. Activity diagram bir sürecin adımlarını, kararlarını ve paralel işlerini gösterir: bir yemek siparişinin müşteriden mutfağa, mutfaktan kuryeye akışı. Sınavda ikisi de “çiz” sorusu olarak gelir; puan detaylardan gelir: geçiş etiketi kalıbı, fork ile decision farkı, swimlane.

Altın kurallar:

1. State machine bir nesne içindir, activity diagram bir süreç içindir.
2. Geçiş etiketi: event [guard] / action. Üçü de opsiyonel ama sıra sabit.
3. Elmas = bir yol seç (decision/merge). Kalın çubuk = hepsi paralel (fork/join).
4. Swimlane = sorumluluk. Her aksiyon doğru şeritte olmalı.

State machine diyagramı

Öğeler

Durum içine üç tür satır yazılabilir: entry / ... (girişte), do / ... (durumdayken), exit / ... (çıkışta).

Event türleri: call event (bir operation çağrısı: pickUp()), time event (after 48h), change event (when dueDate < today), signal event (dış sinyal).

Çözümlü örnek: Copy (kitap kopyası)

Senaryo: “Yeni kopya kataloğa eklenince müsaittir. Bir öğrenci rezerve ederse 48 saat ayrılır; öğrenci gelip alırsa ödünç verilir, gelmezse tekrar müsait olur. Müsait bir kopya doğrudan da ödünç verilebilir. İade tarihi geçerse kopya gecikmiş sayılır. İade edilince müsait olur; gecikmişse iade sırasında ceza kesilir. 30 gün gecikmiş kopya kayıp sayılır ve katalogdan düşülür.”

Adım 1: Durumlar. Available, On Hold, On Loan, Overdue, Lost.

Adım 2: Geçişler.

Adım 3: Çizim.

 ●
 | addToCatalog
 v
+-----------+  reserve /         +---------+
| Available |  startHoldTimer()  | On Hold |
|           |------------------->|         |
|           |<-------------------|         |
+-----------+   after 48h        +---------+
  ^  ^  |                           |
  |  |  | checkOut /               | pickUp /
  |  |  | setDueDate()             | setDueDate()
  |  |  v                           v
  |  | +---------+<-----------------+
  |  +-| On Loan |
  |    +---------+
  | return  | when today > dueDate
  |         v
  |    +---------+  after 30 days  +------+
  +----| Overdue |---------------->| Lost |
return/+---------+  / markLost()   +------+
chargeFine()                          |
                    removeFromCatalog v ◉

Sayım: 5 durum, 10 geçiş (başlangıç ve bitiş okları dahil).

TUZAK · durumu aksiyonla karıştırmak. “Ceza kes” bir durum değildir, bir action’dır (geçişte / chargeFine()). Durum, nesnenin bir süre kaldığı koşuldur ve genelde sıfat ya da hal bildirir: Available, Overdue.

Activity diyagramı

Activity diagram bir iş sürecini ya da bir use case’in akışını gösterir. Akış şemasına benzer ama paralellik (fork/join) ve sorumluluk (swimlane) ekler. Ders kitabının çerçevesinde fonksiyonel modellemenin de parçasıdır; use case’lerin içini görselleştirmek için kullanılır.

Öğeler

Çözümlü örnek: yemek siparişi (swimlane’li)

Senaryo: “Müşteri sipariş verir ve öder. Ödeme reddedilirse başka kart dener. Restoran siparişi değerlendirir; reddederse müşteriye bildirilir ve süreç biter. Onaylarsa yemek hazırlanırken aynı anda bir kurye atanır. İkisi de bitince kurye siparişi alır, teslim eder; müşteri teslimatı onaylar.”

 Customer      | Restaurant     | Courier
---------------+----------------+-------------
 ●             |                |
 |             |                |
 [Place Order] |                |
 |             |                |
 [Pay]<----+   |                |
 |         |   |                |
 <dec>-----+   |                |
 |  [declined] |                |
 | [paid]      |                |
 +------------>[Review Order]   |
               |   |            |
 [Get notice]<-+--<dec>         |
 |  [rejected] |   | [accepted] |
 ◉             |   |            |
               | ==+== (fork)   |
               | |       |      |
               |[Prepare]+----->[Assign
               | Food]   |      | Courier]
               | |       |      |  |
               | ======= (join)<---+
               |    |           |
               |    +---------->[Pick Up]
               |                |  |
               |                [Deliver]
 [Confirm      |                |  |
  Receipt]<----+----------------+--+
 |             |                |
 ◉             |                |

Okuma:

• 3 swimlane: Customer, Restaurant, Courier.
• 2 decision: ödeme sonucu ([paid] / [declined]) ve restoran kararı ([accepted] / [rejected]).
• 1 fork, 1 join: Prepare Food ile Assign Courier paralel; Pick Up ikisinin bitmesini bekler.
• 2 activity final: reddedilen sipariş ve normal bitiş.

İPUCU · decision sonrası merge. Decision ile ayrılan yollar tekrar birleşecekse bir merge elması kullan. Ödeme döngüsünde reddedilen yol tekrar “Pay”e döner; bu dönüş Pay’den önce bir merge ile çizilirse daha düzgün olur.

TUZAK · fork yerine decision. “Yemek hazırlanırken aynı anda kurye atanır” cümlesindeki “aynı anda” fork demektir. Decision kullanırsan ikisinden sadece biri olur.

Hangi diyagram ne zaman?

Sık yapılan hatalar