Ana içeriğe atla

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde (1, 2) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım.
“Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.”
Ivar Jacobson Senaryo tanımı için der ki:
“Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ”
UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır.
Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler, Sistem (Proje kapsamını belirtir), Use Caseler ve bunlar arasındaki ilişkiler. Şekil1’de use case diyagramlarını oluşturan dört ana elemanının gösterim şekli bulunmaktadır.
image
Şekil 1. Use Case Diyagram
Use case diyagramlarda senaryolar aktör tarafından tetiklenmektedir. Aşağıdaki senaryoda aktör senaryoyu başlatır, use case sonucunda elde edilen değer diğer aktöre verilir.
image
Şekil 2. Use Case Diyagram Örneği
Use case’ler tekrar kullanılabilen birimlerdir. Tekrar kullanımı sağlayan yöntemler inclusion (içerme) ve extension (genişletme) dır. Tekrar kullanım yöntemleri dışında use caseler arasındaki ilişkiyi gösteren yöntemler ise Generalization (Genellleme) ve Grouping (gruplama) dır. Bunlar Use Case’ler arasındaki ilişkiyi gösteren kavramlardır. Bu kavramları detayları ile inceleyelim.

İçerme (Include, uses):  Birçok senaryo grubunda kullanılan başka bir senaryo grubudur. İçerme ilişkisi senaryo(lar) içerisinde iki veya daha fazla tekrarlanan adım var ise tekrar edilen kısımlar ayrı Use  case olarak bölüp içerme  ilişkisi kullanılmalıdır. Bir senaryonun içinden bir alt programa dallanıp geri dönmek gibidir.
image
Şekil 3. İçerme (Include, uses)
Genişletme (Extend): Senaryo grupları doğal akışa göre hazırlanır. Çeşitli koşullar altında bu doğal akıştan sapmalar olabilir. Genişletme ilişkisi ana senaryodan ayrılma noktasından sonra yapılanları belirtir. Genelleme ilişkisine benzemekle birlikte farkı genişleme noktalarının dışında genişleme yapma imkanının bulunmayışıdır. Dolayısıyla kullanıcıya daha sınırlı ve kontrollü genişleme noktaları sunar.
image
Şekil 4. Genişletme (Extend)
Genelleme (Generalization): Sınıflar arasındaki türeme ilişkisine benzer. Genel bir senaryo grubundan özel bir senaryo grubu türetilir.
Gruplama(Groupping): Use Case’leri bir arada toplamak için kullanılan tekniktir. Gruplama tekniği genellikle birkaç alt sistemden oluşan büyük sistemlerde kullanılır.
UML diyagramlarında bir şeklin anlamını açıklayan özel sözcükler (sterotype) <<...>> simgeleri arasına yazılır. Aktörler çizgi adam şeklinde gösterildiği gibi bir dikdörtgen ile de ifade edilebilir. Bu durumda dikdörtgenin anlamını belirtmek için “streotype” kullanılır.
Örnek Diyagram ve Dökümantasyon
Otel rezervasyon sisteminde, sistemle etkileşimde olan 4 ana aktör ya da rol bulunmaktadır. Muhasebe aktörü genel bir kullanıcı olmayıp, otel rezervasyon sisteminden etkilenen dış sisteme ait bir yazılımı temsil etmektedir. Bunu aktörlerin Use Case’leri kullanırken çizilen bağlantıların ok yönünden kestirebiliriz. Use Case’lerden etkilenen aktörlerde ok yönü Use Case’den aktöre doğru iken normal kullanıcılarda, aktörden Use Case’lere doğru bir geçiş olduğunu siz de farketmişsinizdir. Diyagramdan da görüldüğü gibi otel rezervasyon sistemi Otel Giriş/Çıkış, Yeni Rezervasyon, Rezervasyon Değişilik gibi üç ana Use Case’den oluşmakta, diğer Use Case’ler ise ana Use Case’ler ile ilişkide bulunan alt Use Case’ler olarak adlandırılabilir.
image
Şekil 5. Otel Rezervasyon Use Case Diyagramı
Use Case Dökümantasyonu
Yaptığımız analizin Use Case diyagramını oluşturmak ne kadar önemli ise bu senaryonun dökümante edilmesi de o denli önemlidir. Use case dökümantasyonunun standart bir formatı yoktur. Her firma kendisine uygun format belirleyebilir. Temel dökümantasyon formatı aşağıdaki gibidir. İhtiyaçlar doğrultusunda eklemeler yapılabilir.
  • Adı: Senaryo adı
  • Aktörler: Senaryoda etkileşimde olan aktörler
  • Ön Koşullar: Senaryonun başlayabilmesi için gerekli ön koşullar
  • Sonuç Koşullar: Senaryo sonunda ne olduğu tanımlanır
  • Genişleme Noktası: Sadece genişleme özelliğinin kullanılacağı durumlarda bu alan kullanılır. Genişleme noktaları başarılı senaryo içersinde bulunan bir adıma referans verir.
  • Başarılı Senaryo: Aktörlerin başarıyla Use Case hedefini gerçekleştirdiği adımlar dizisidir. Senaryo büyük bir işlemi ifade eder, bu kullanıcının 3-4 dakika ile yarım saat arasında tamamladığı ve sonunda tarafların orta hedefe ve faydaya ulaştıkları durumdur. Bu tanımdan da anlaşılacağı üzere Use Case ler kapsamlı operasyonları içermektedir.
  • Alternatif Yollar: başarılı senaryo üzerinde bazı adımlarda aktör alternatif adımlar ile yoluna devam edebilir. Alternatif referansları başarılı senaryo adımları üzerinde gösterilir. (Ör: A1, A2)
Şekil 5’de  otel rezervasyon işleminin diyagramını incelemiştik.  Şimdi de use case dökümantasyonunu inceleyelim.
  • Adı: Yeni Rezervasyon
  • Aktörler: Resepsiyon Görevlisi, Rezervasyon Görevlisi, Muhasebe
  • Ön Koşullar: Sisteme login olunmalıdır Son Durum: Muhasebe sistemi ve rezervasyon kayıt sistemi güncellenir.
  • Genişleme Noktası: Rezervasyon Tipi, müşteri bilgi kaydı
  • Başarılı Senaryo:
    1. Müşteriye oda tipleri sunulur
    2. Müşteri oda tipini seçer
    3. Müşteri konaklama başlangıç tarihini ve konaklama süresini girer
    4. Müşteri mevcut odalar üzerinde arama yapar
    5. Eğer oda bulunamamışsa (A1)
    6. Oda bulunmuştur, fiyat görüntülenir
    7. Müşteri teklifi reddederse (A2)
    8. Müşteri bilgilerini girer
    9. Rezervasyon Yapılır
    10. Rezervasyonda anlaşılan fiyat kayıt edilir ve rezervasyon numarası verilir
    11. Muhasebe sistemi haberdar edilir
  • Alternatif Yollar:
    • A1. farklı bir oda tipi yada tarih deneyin mesajı ile 2. adıma geri döner
    • A2. Use case iptal edilir ve herhangi bir değişiklik yapılmaz
Use Case Senaryolarının Avantajları
  • Sistemin erişimini, sınırlarını belirler. Böylelikle geliştirilecek sistemin boyutunu ve karmaşıklığını kafamızda daha rahat canlandırabiliriz.
  • Kullanım senaryoları isteklerin çözümlenmesine çok benzemektedir: daha nettir ve tamdır.
  • Basit oluşu müşteri ile geliştirme ekibi arasında iletişime olanak tanır. Geliştirme aşaması için temel oluşturur.
  • Sistem testi için temel oluşturur.
  • Kullanıcı klavuzu hazırlamaya yardımcı olur.
Use Case senaryolarının oluşturulması
  1. Aktörlerin belirlenmesi
    • Sistemin temel işlevlerini kim kullanacak?
    • Sistemin bakımını ve işletimini kim yapacak?
    • Sistem hangi cihazları kullanacak?
    • Diğer hangi sistemlerle etkileşimde bulunacak?
    • Sistemin çıkışlarını kimleri ilgilendirir?
  2. Aktörlerden yararlanarak sistem davranışının belirlenmesi
    • Aktörlerin temel işlevi nedir?
    • Aktör sistem bilgilerine erişmeli mi?
    • Durum değişiklikleri aktöre bildirilecek mi?
    • Aktör hangi işlevlere ihtiyaç duyar?
  3. Bazı davranışlar aktörlerden yola çıkarak belirlenemeyebilir. Bu durumda aşağıdaki soruları da sormak uygun olur:
    • Sistemin gerek duyduğu giriş ve çıkış nedir?
    • Sistem dış olaylardan etkilenir?
    • Şu andaki sistemin eksiklikleri ve problemleri nelerdir?
    • Periyodik olarak gerçekleştirilen işlemler var mı?
  4. Use Case Senaryolarının Saptanmasındaki adımlar
    • Olası sistem kullanıcıları ile görüşme yapılmalı
    • Olası tüm aktörlerin saptanması
    • Olası tüm senaryolar saptanır
    • Her senaryo için Kullanım Senaryo Anlatımı kağıda aktarılır ve doğrulanır
    • Senaryo bilgisayarda oluşturulur
Use Case Diyagram Oluşturulurken Nelere Dikkat Edilmeli?
  • Aktörler tespit edilirken sistemde çok sık adı geçen özneler kullanılmalı Özneler çıkarılırken rollere göre gruplandırılmalıdır. Aktör sayısının en aza indirilmesine özen gösterilmelidir.
  • Use Case diyagramları oluştururken cümleler arasında geçen kilit fiiller önemlidir. fiillerin çok sık geçmesi ve bunların projenin ana hedeflerine uygun, sisteme değer katan iş süreçlerini içermesine dikkat edilmelidir.
  • Use Case diyagramlardaki en önemli ilişkinin içerme ilişkisi olduğunda hem fikir olduğumuzu düşünerek içerme ilişkisini kullanmaya özen gösterin. Zorunlu olmadıkça diğer ilişkileri kullanmaktan kaçınılmalıdır.
  • Use Case diyagramlarının kullanım amacını unutmamak gerekir. Çok fazla Use Case diyagramı çizmekten ziyade kolaylıkla anlaşılabilir, kullanıcılar için değer taşıyabilen çekirdek iş süreçlerini anlatan diyagramlar olmalıdır.
Bir sonraki makalemizde Class(Sınıf) diyagramlarını ayrıntılı inceleyeceğiz.
Referanslar
Neslihan ÇALIŞKANEL, Deniz KILINÇ

Yorumlar

  1. bence emrah saçmalıyosun....hiç bir hata yok...atıf almak için çabalıyosun ama yemezler

    YanıtlaSil
  2. Use Case konusunda rastladığım en kaliteli makaledir. Her bir noktaya detaya girilmeden değinilmiş tebrikler.

    YanıtlaSil
  3. Yorumunuz için teşekkürler Özgür Bey :)

    YanıtlaSil
  4. use case hakkında birçok makale okudum ama bu bıraz daha ayrıntılı olmus uzun olmasına ragmen sıkılmadım tesekkurler

    YanıtlaSil
  5. çok güzel anlatmışsınız teşekkür ederim fakat bir sorum olacak Otel Rezervasyon Use Case diyagramında otel görevlisinin etkilendiği uses case de "otel çıkış/çıkış" yazıyor burada bir hata var mı? "otel giriş/cıkış" olması gerekmiyormu ?

    YanıtlaSil
  6. çok yararlı oldu teşekkürler...

    YanıtlaSil
  7. Tek kelimeyle süper bi makale :)

    YanıtlaSil
  8. Çok işime yaradı hocam teşekkürler

    YanıtlaSil
  9. Elinize sağlık teşekkürler

    YanıtlaSil
  10. verilen örnek güzelmiş. teşekkürler.

    YanıtlaSil
  11. çok yararlı oldu teşekkürler...

    YanıtlaSil
  12. Paylaşımlarınıza Teşekkür Ediyorum.

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e