Kullanım Durumu Diyagramı Örneği: Aktörler, Kullanım Durumları, Include ve Extend

Kullanım durumu diyagramı tek bir sayfada tek bir soruyu cevaplar: Bu sistemi kim kullanıyor ve ne için kullanıyor? Ürün yöneticileri onu kapsam üzerinde anlaşmak, mühendisler bir sisteme giriş noktalarının hepsini görmek, test uzmanları da her hedefin bir yolu olduğunu kontrol etmek için kullanır. Aynı zamanda en sık yanlış çizilen UML diyagramlarından biridir: İnsanlar onu akış şemasına çevirir, her düğmeyi bir kullanım durumu olarak çizer ya da include ve extend'i ters kullanır.

Bu yazı gösterimi UML 2.5.1 spesifikasyonunun tanımladığı şekliyle açıklıyor, include ile extend farkını basit bir testle netleştiriyor, bir yemek siparişi uygulaması için baştan sona bir örnek üzerinden ilerliyor, her ovalin arkasında durması gereken metni gösteriyor ve kullanım durumu diyagramlarını işe yaramaz hâle getiren hataları listeliyor.

Gösterim

Okların yönleri doğrudan OMG'nin Aralık 2017'de yayımladığı UML 2.5.1 spesifikasyonundan gelir: include, temel kullanım durumundan dahil edilene doğru; extend ise genişleten kullanım durumundan genişlettiği kullanım durumuna doğru gösterir. Spesifikasyon ayrıca genişleme noktalarına da izin verir: temel kullanım durumunda bir genişlemenin bağlanabileceği, ovalin içinde listelenen adlandırılmış yerler.

Include ve extend: tek bir test

Temel kullanım durumunun diğeri olmadan eksiksiz olup olmadığını sorun.

• Onsuz eksikse: include. Sipariş vermek her zaman ödeme almayı gerektirir. “Place order”, “Pay for order”ı dahil eder. Ok dahil edilen kullanım durumunu gösterir ve temel olan onsuz çalışamaz.
• Onsuz da eksiksizse: extend. Promosyon kodu uygulamak isteğe bağlıdır; kodsuz bir sipariş de tamamen geçerlidir. “Apply promo code”, müşterinin bir kodu olduğunda “ödemeden önce” gibi bir genişleme noktasında “Place order”ı genişletir. Ok temel kullanım durumunu gösterir; temel olan genişlemenin varlığından haberdar bile değildir.

Kötüye kullanımın çoğunu iki kural daha önler:

• Include'u, kimlik doğrulama ya da ödeme gibi birkaç kullanım durumunun ihtiyaç duyduğu davranışı paylaşmak için kullanın. Bir kullanım durumunu adımlara bölmek için kullanmayın; o bir akış şemasıdır.
• Extend'i idareli kullanın. Temel kullanım durumlarından daha fazla extend'iniz varsa hedefleri değil, arayüz seçeneklerini belgeliyorsunuz demektir.

Aktörler roldür

Aktör bir roldür; bir kişi ya da iş unvanı değildir. Aynı kişi sabah müşteri, öğleden sonra restoran müdürü olabilir. Aktörler sistem de olabilir: Uygulamanın bir kartı onaylatmak için çağırdığı ödeme sağlayıcısı destekleyici bir aktördür. Bazı ekipler zamanlanmış işleri bir “Time” aktörüyle modeller; bu, kimsenin elle başlatmadığı kullanım durumları için yaygın bir gelenektir.

Geleneksel olarak, hedeflerine ulaşmak için kullanım durumlarını başlatan birincil aktörler solda, sistemin başvurduğu destekleyici aktörler sağda durur.

Kullanım durumlarını doğru seviyede adlandırmak

Kullanım durumlarını aktörün bakış açısından fiil ve nesneyle adlandırın: “Sipariş”, “Sipariş ekranı” ya da “Gönder düğmesi” değil, “Sipariş ver”. Her biri, aktörün tek oturuşta tamamlayabileceği ve ulaştığında memnun olacağı bir hedef olmalıdır; Alistair Cockburn buna kullanıcı hedeflerinin deniz seviyesi der. Daha yüksek seviyeler (“Restoranı işlet”) tek bir oval için fazla geniştir; daha düşük seviyeler (“Kart numarasını gir”) bir kullanım durumunun içindeki adımlardır.

Baştan sona bir örnek: yemek siparişi

Aşağıdaki diyagram dört aktörlü bir yemek siparişi uygulamasını gösteriyor:

• Customer menüye göz atar, sipariş verir ve teslimatları takip eder.
• Restaurant staff siparişleri kabul eder.
• Courier siparişleri teslim eder.
• Payment provider, harici bir sistem olarak ödemeyi destekler.

Sınırın içinde de yedi kullanım durumu var:

1. Browse menu
2. Place order; Pay for order'ı dahil eder
3. Pay for order; ödeme sağlayıcısı bunu destekler
4. Apply promo code; ödemeden önce Place order'ı genişletir
5. Track delivery
6. Accept order
7. Deliver order

Diyagramda olmayanlara dikkat edin: adımların sırası yok, ekranlar yok, her aktör için bir “Log in” ovali yok. Kimlik doğrulama bir hedef değil, bir ön koşuldur; açıklamalarda yer alır ya da gerçek bir davranış taşıyorsa dahil edilen tek bir kullanım durumu olur.

Her ovalin arkasındaki açıklama

Diyagram bir dizindir. Asıl değer, her kullanım durumu için yazılan kısa açıklamadadır; örneğin:

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

Açıklamadaki uzantılar, yani numaralı “ya şöyle olursa” dalları, gereksinimlerin ve test senaryolarının çıktığı yerdir. Diyagramdaki extend ilişkilerinden çok daha ayrıntılıdırlar; diyagram yalnızca resmedilmeye değer isteğe bağlı hedefleri göstermelidir.

Sık yapılan hatalar

• Kılık değiştirmiş bir akış şeması. Kullanım durumları arasında “sonra” anlamına gelen oklar diyagramı bir süreç modeline çevirir. İş sırası için bir BPMN diyagramı ya da aktivite diyagramı kullanın.
• Her CRUD işlemi için bir kullanım durumu. “Menü öğesi oluştur”, “Menü öğesini güncelle” ve “Menü öğesini sil” genellikle tek bir hedeftir: “Menüyü yönet”.
• Kullanım durumu olarak ekranlar ve düğmeler. “Ödeme düğmesine tıkla” bir adımdır, hedef değil.
• Ayrıştırma için include. Her kullanım durumu üç başkasını dahil ediyorsa diyagram kullanıcı hedeflerini değil, kod yapısını anlatıyordur.
• Aktör olarak iç bileşenler. Veritabanı bir aktör değildir; sistemin içindedir. Çağırdığınız harici sistemler ise aktördür.
• Sınır yok. Konu dikdörtgeni olmadan okuyucular neyi inşa ettiğinizi ve neye bağımlı olduğunuzu ayırt edemez.

Kullanım durumu diyagramları, kullanıcı hikâyeleri ve sekans diyagramları

Birlikte çalışırlar: Kullanım durumu diyagramı alanın haritasını çıkarır, hikâyeler onu teslim edilebilir parçalara böler, bir sekans diyagramı da tek bir senaryonun gerçekte nasıl işlediğini gösterir.

Kullanım durumu diyagramı

Nasıl okunur:

• Dikdörtgen sistem sınırıdır: İçindeki her şey yemek siparişi uygulamasıdır.
• Soldaki aktörler kullanım durumlarını başlatır: Müşterinin üç hedefi, restoran çalışanlarının ve kuryelerin birer hedefi var.
• Sağdaki ödeme sağlayıcısı, uygulamanın ödeme sırasında çağırdığı destekleyici bir sistemdir.
• Place order'dan Pay for order'a giden «include» oku ödemenin her zaman gerçekleştiğini gösterir. Apply promo code'dan Place order'a giden «extend» oku ise promosyon kodunun isteğe bağlı olduğunu gösterir.
• Markdown bloğu, UML'ye yeni başlayan okuyucular için bir gösterim anahtarıdır.

İnsanların gerçekten okuduğu kullanım durumu diyagramları çizmek

• Diyagram başına yaklaşık 15 kullanım durumunun altında kalın. Bir sistemde daha fazlası varsa aktöre ya da alt sisteme göre bölün.
• Birincil aktörleri sola, destekleyici aktörleri sağa koyun, böylece okuma yönü neyi kimin başlattığıyla örtüşür.
• Include ve extend'i açıkça, açılı tırnaklarla etiketleyin ve okları kesikli tutun.
• Ayrıntıları açıklamalara bırakın. Diyagram bir slayta sığmalı; metin gerektiği kadar uzun olabilir.

Kullanım durumu diyagramları diğer UML görünümleriyle iyi eşleşir: alan modeli için UML sınıf diyagramı örneği, bir siparişin yaşam döngüsü için de durum diyagramı örneği.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Sistem sınırı olarak Food ordering app adlı bir Temel Çerçeve ekleyin.
3. Çerçevenin içine UML paketinden yukarıdaki adlarla yedi Kullanım durumu düğümü ekleyin.
4. UML paketinden dört Aktör düğümü ekleyin: Customer, Restaurant staff ve Courier solda, Payment provider sağda.
5. Aktörleri kullanım durumlarına düz çizgilerle bağlayın. Place order'dan Pay for order'a «include» etiketli, Apply promo code'dan Place order'a da «extend» etiketli kesikli kenarlar ekleyin.
6. Kısa bir gösterim anahtarıyla Temel paketinden bir Markdown bloğu ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Kullanım durumu diyagramında include ile extend arasındaki fark nedir? Include, temel kullanım durumunun dahil edilen davranışı her zaman gerçekleştirdiği anlamına gelir ve ok dahil edilen kullanım durumunu gösterir. Extend, bir koşula bağlı olarak eklenen isteğe bağlı davranıştır ve ok genişlemeden temel kullanım durumuna doğru gösterir.

Bir aktör sistem olabilir mi? Evet. Sistemle etkileşen her dış rol bir aktör olabilir; ödeme sağlayıcısı gibi başka yazılımlar da buna dahildir. Sisteminizin içindeki bileşenler aktör değildir.

Oklar aktörleri kullanım durumlarına bağlamalı mı? UML, aktörler ile kullanım durumları arasında düz ilişkilendirme çizgileri kullanır. Bazı ekipler kimin başlattığını göstermek için ok uçları ekler, ancak standart gösterim bunu gerektirmez.

Bir diyagramda kaç kullanım durumu olmalı? Yol gösterici bir kural olarak en fazla 15 kadar. Daha büyük sistemler, aktöre ya da alt sisteme göre bölünmüş birkaç diyagram olarak daha iyi okunur.

Kullanım durumu diyagramları adımların sırasını gösterir mi? Hayır. Sıraları değil, hedefleri gösterirler. Adımların sırası kullanım durumu açıklamalarına, aktivite diyagramlarına ya da sekans diyagramlarına aittir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.