Use case ve use case diyagramları

Use case modeli fonksiyonel modellemenin başlangıcıdır: kullanıcıların sistemle ne yapmak istediğini gösterir. Diyagram kendisi basittir (çöp adamlar, ovaller, çizgiler) ama sınavda puan kaybı tam olarak detaylardan gelir: include ile extend’i karıştırmak, okun yönünü ters çizmek, bir adımı use case yapmak, veriyi aktör sanmak. Tipik sınav sorusu: bir paragraf senaryo verilir, “Identify the actors and use cases and draw the use case diagram” denir.

Altın kurallar:

1. Actor bir roldür, sistemin dışındadır. İnsan, dış sistem ya da zaman olabilir.
2. Use case aktöre değer veren bir hedeftir. Adı fiil + nesne: “Book Class”.
3. Include zorunlu, extend koşullu. Include oku temelden eklenene, extend oku genişletenden temele.
4. Generalization üçgen uçlu düz çizgi, alttan üste.

Temel öğeler

Actor

Aktör, sistemin dışında kalan ve sistemle bilgi alışverişi yapan bir roldür. Sınavda dikkat edilecek üç nokta:

• Rol, kişi değil. “Ahmet Hoca” değil “Instructor”.
• Dış sistemler aktördür. Ödeme sağlayıcısı, üniversitenin öğrenci bilgi sistemi.
• Zaman aktör olabilir. “Her ay sonu rapor üret” gibi otomatik işleri başlatan “Time” aktörü.

Primary actor use case’i başlatan, ondan değer alan aktördür. Secondary (supporting) actor sistemin işi yapmak için yardım aldığı aktördür (ör. Payment Service).

Use case

Bir use case, aktörün sistemle gerçekleştirdiği ve sonunda “işim bitti” diyebileceği tam bir hedeftir. Kontrol soruları:

• Aktöre değerli bir sonuç veriyor mu?
• Tek oturumda (bir seferde) tamamlanıyor mu?
• Aktörün dilinde mi, teknik dilde mi?

İyi: “Reserve Book”, “Pay Fine”, “Track Order”. Kötü: “Login Screen” (ekran), “Validate Input” (adım), “Database” (teknoloji).

İlişkiler

Association

Aktörle use case arasındaki düz çizgi. Aktörün bu use case’e katıldığını gösterir. Okun olması şart değildir. İsteğe bağlı olarak çokluk (multiplicity) yazılabilir.

Include

Birden çok use case’in her seferinde ihtiyaç duyduğu ortak davranış ayrı bir use case’e çıkarılır. Temel use case, eklenen olmadan tamamlanamaz.

(Book Class) - - <<include>> - -> (Verify Membership)
(Check In)   - - <<include>> - -> (Verify Membership)

Extend

Temel use case’e sadece belirli bir koşulda eklenen davranış. Temel use case, extend olmadan da tamamlanabilir. Genişleme noktası (extension point) temel use case içinde adlandırılabilir.

(Pay Reactivation Fee)
      - - <<extend>> - -> (Renew Membership)
  koşul: üyelik 30 günden fazla önce bitmiş

TUZAK · ok yönleri. Include: “Book Class, Verify Membership’i içerir” → ok Book Class’tan çıkar. Extend: “Pay Reactivation Fee, Renew Membership’i genişletir” → ok Pay Reactivation Fee’den çıkar. Cümleyi kur, ok öznede başlar.

Generalization

Actor generalization: Alt aktör, üst aktörün tüm ilişkilerini miras alır. Front Desk Staff ve Trainer, Staff’ın özel halleridir.

Use case generalization: Bir use case’in özel türleri. “Pay Fee” genel, “Pay by Card” ve “Pay by Cash” alt türler.

Front Desk Staff ---|>  Staff
Trainer          ---|>  Staff
(Pay by Card)    ---|>  (Pay Fee)

---|> burada içi boş üçgen uçlu düz çizgiyi temsil ediyor.

Include, extend, generalization karşılaştırma

Çözümlü örnek: FitHub spor salonu

Senaryo: “Bir kişi resepsiyonda ön büro görevlisi aracılığıyla üye olur. Üyeler üyeliklerini online yeniler; üyelik 30 günden fazla önce bitmişse yeniden aktivasyon ücreti öderler. Ödemeler dış bir ödeme servisi üzerinden alınır. Üyeler grup derslerine rezervasyon yapar ve rezervasyonlarını iptal eder. Salona girişte turnikede check-in yaparlar. Rezervasyon ve check-in için üyeliğin aktif olduğu her seferinde doğrulanır. Antrenörler ders programını yönetir. Her ay sonunda sistem otomatik olarak aylık rapor üretir ve yöneticilere gönderir. Ön büro görevlileri ve antrenörler personel olarak ortak işleri paylaşır.”

Adım 1: Aktörleri bul. İsimleri tara, sistemle etkileşen rolleri seç.

Adım 2: Use case’leri bul. Fiilleri tara.

Adım 3: Diyagram.

+------- FitHub Membership System ---------+
|                                          |
|  (Register Member)                       |
|  (Renew Membership)<-<<ext>>-(Pay React. |
|        |                       Fee)      |
|  (Book Class)--<<inc>>-->(Verify         |
|  (Check In)----<<inc>>--> Membership)    |
|  (Cancel Booking)                        |
|  (Manage Class Schedule)                 |
|  (Generate Monthly Report)               |
+------------------------------------------+

Associations (dışarıdan):
 Member ......... Renew, Book, Cancel, Check In
 FrontDeskStaff . Register Member
 Trainer ........ Manage Class Schedule
 Payment Service  Renew Membership
 Time ........... Generate Monthly Report
Generalization:
 Front Desk Staff --|> Staff
 Trainer          --|> Staff

Adım 4: Kontrol.

• Her aktör en az bir use case’e bağlı mı? Evet. (Staff üst aktör; ortak bir use case eklenirse, ör. “View Member Profile”, ona bağlanır.)
• Her use case’e bir aktör ulaşıyor mu ya da include/extend ile bağlı mı? Evet.
• Sınır içinde 9 use case var. Okunabilirlik sınırında; daha büyük sistemde paketlere bölünür.

Use case nereden gelir?

Use case’ler 5. haftada topladığın functional gereksinimlerden türetilir. Her functional gereksinim en az bir use case’e izlenebilmeli (traceability). Nonfunctional gereksinimler diyagramda görünmez; ilgili use case description’ın “special requirements” kısmına yazılır (7. hafta).

Sık yapılan hatalar