İsmail Kırbaş ile Tasarım Yolculuğu [AnaSayfa] İsmail Kırbaş ile Tasarım Yolculuğu [AnaSayfa] İsmail Kırbaş ile Tasarım Yolculuğu [AnaSayfa]
 Site Haritası 
 
Site Map
Ana SayfaYeriniz | Ana Sayfa | Makaleler | Programcılık | Use Case Diyagramları İle Başarılı Proje Analizi

Diğer Yazılar
PHP
JavaScript
CSS
XHTML
MySQL
XML
On Yılda Programlama Öğrenin
Yazılım Mimarlığı
Programlamanın Taosu
Anti Pattern
Kötü Tasarımın Belirtileri
RSS Dosya Yapısı
Flash Oyunları
Ajax
Android


E-posta Gönderin Yorum Yazın
Güvenlik Kodu:4266Güvenlik Kodu:4266Güvenlik Kodu:4266Güvenlik Kodu:4266




En Son Okunan 10 Makale
  1. İnternette Marka Olmanın Anahtarları
  2. Diyafram ve Enstantane
  3. Kablosuz Ağlarda Saldırı ve Güvenlik
  4. İletişim
  5. Kriz Yönetimi 1
  6. Dijital Fotoğraf Çekim Teknikleri
  7. Zaman Yönetimi
  8. Yüksek Lisans Çalışmaları
  9. Fotoğraf Çekim Teknikleri
  10. Tasarım İpuçları
 
Use Case Diyagramları İle Başarılı Proje Analizi>
Yazı Tipi KüçültYazı Tipi BüyütAna SayfaYazıcıdan ÇıkarPDF Belgesi Olarak GörüntüleFavorilerime EkleArkadaşıma Tavsiye EdeceğimRTF (Word Dokümanı) olarak görüntüle

Analiz aşaması projeler için hayati önem taşır. İyi bir analizden geçmemiş projelerin başarı şansı bir hayli azdır. Analiz ile birlikte kendimize “Ne?” sorusunu yöneltirken, sistemin fonksiyonel gereksinimlerini yakalamaya çalışırız. Use Case UML içerisinde yer alan ve analiz aşamalarında sıkça kullanılan bir tekniktir.
 
Başarılı projelere göz attığımızda, bu projelerin çok iyi analiz aşamaları geçirdikleri görülür. Analiz ve tasarım genellikle birlikte kullanılan iki terim. Bu iki terimi kısaca şu iki kelime ile açıklamak mümkün. Ne? ve Nasıl? Ne sorusu analizi temsil ederken, Nasıl sorusu ise tasarım etkinliğinden sorumludur. Ne sorusunun cevabı nasıl sorusunu tetiklediğinden tasarım analizin dolaylı bir sonucudur.
 
Teknik ekip projeye başlarken yaptığı işin süreçleri hakkında çok fazla bilgiye sahip değildir. Projenin hedeflerine ulaşması müşterinin ve teknik ekibin aynı hat üzerinde yürüyor olmasına, bir başka deyişle aynı dili konuşuyor olması ve ortak bir metafora sahip olmasına bağlıdır. Başta geçirilen başarısız bir analiz ve beraberinde yanlış anlaşılan gereksinimler şu sonuçları doğurabilir;
  • Tasarımın çöpe atılması ve yüksek geliştirme maliyeti
  • Projenin müşteri ihtiyaçlarına cevap verememesi ve projenin olası iptali
  • Geçici (Ad Hoc) çözüm ve yamalar ile projenin tıkanması
  • Ve nihayetinde değerli müşterinizi kaybetmek J
Yazımızda Use Case (UC) diyagramları ile uygulama analizi ve  başarılı analizlerin püf noktaları üzerinde durmaya çalışacağız. Diyagram örnekleri için Microsoft’un Visio 2003 programı kullanılacaktır.
 
UC Öğeleri:
 
UC temelde çok basit bir tekniktir, esas zorluk gereksinimleri hedef odaklı en etkin biçimde ifade edebilmektir. Sistem,yani üzerinde çalıştığımız uygulama ile uygulamadan etkilenen dış kullanıcılar(aktör) arasında geçen iş hedeflerine uygun bir dizi etkileşime Use Case denir. Size belki bu aşamada bu tanım biraz karışık gelmiş olabilir, şimdi isterseniz tanımda geçen terimleri biraz açalım. Tanımlara geçmeden temel bir UC diyagramını gösterelim.
 
 
Senaryo     : Sistem ve aktör (kullanıcı) arasında geçen etkileşimi anlatan bir dizi adım’a (operasyon) senrayo adı verilir. Basit bir senaryo örneği verecek olursak, online bir mağazadan ürün satın alma işlemini düşünebiliriz. Ürün satın alma senaryosu için şu adımları sırasıyla örnek verebiliriz;
  1. müşteri ürün kataloğunu gezer,
  2. müşteri ürün detaylarını inceler,
  3. Müşteri ürünü sepete ekler,
  4. Müşteri sipariş işlemine geçer,
  5. teslimat ve fatura bilgileri girilir,
  6. ödeme bilgileri girilir,
  7. sistem tarafından sipariş onayı alınır,
  8. teslimat oluşturulur ve kargo şirketine iletilir,
  9. müşteri ürünü teslimat adresinden teslim alır
gibi bir dizi işlem başarılı bir ürün satın alma senaryosunu oluşturur.
 
Aktör          : Aktör belirlenen sistem üzerinde bir rol oynayan ve etkileşime geçen her türlü öğedir. Burada aktör sistemi kullanan bir site ziyaretçisi olabileceği gibi sistemden etkilenen dış sistemler yani kargo şirketide bir aktör olarak yerini alır. Yukarıdaki senaryoda müşteri Use Case’i tetikleyen, kargo şirketi ise tetiklenen yani UC’den etkilenen aktörlerdir. Aktör kelimesi bazen yanlış anlaşılmalara neden olabilir, bu yüzden aktör kelimesini açmak için; sistem üzerinde belli bir role sahip kullanıcı, açıklamasını getirmek yerinde olur sanırım.
 
Sistem       : Use Case’lerin yer aldığı sınırları ve kapsamı belli, aktörlerin üzerinde çalıştığı yer sistemdir. Sistem projelerinizin kapsamını belirtmesi açısından önemlidir.
 
Use Case    : Ortak bir kullanıcı hedefi etrafında oluşturulmuş bir takım senaryoların bütünleşmesinden meydana gelen yapıdır. Use caseler temelde senaryolardan oluşur, fakat her senaryo yukarıda verilen örnek gibi başarılı ve tek düze yürümez. Senaryoların bazı istisnai durumları ve alt senaryoları içermesi gerekmektedir. Bu durumda Use Case verilen senaryoların ötesinde bazı artı özellikler de taşır. Örnek olarak müşterinin ödeme işlemini havale yada kredi kartı olarak yapabilmesi, kredi kartı onayında hata alınması ve teslimat seçenekleri gibi istisnai durum ve alternatif yaklaşımların başarılı senaryo üzerinde toparlanması işlemi UClerin sorumluluğu altındadır.
 
İlişki          : UCler arasında kurulan ilişkiler, bu ilişkiler ileriki bölümlerde daha detaylı anlatılacaktır. İlişkilerin yardımı ile UCler üzerinde genelleme, kapsama (inclusion) ve genişleme (extension) gibi gösterimler yapılabilir.
 
Analiz
Dilerseniz örnek bir diyagram üzerinden UClerin detaylarına inmeye çalışalım. Aşağıdaki örnekte Otel rezervasyon sistemi üzerinde durulacak.
 
 
Kısaca örnek diyagramı açıklamaya çalışalım. Otel rezervasyon sisteminde sistemle etkileşimde olan 4 ana aktör yada rol bulunuyor. Muhasebe aktörü genel bir kullanıcı olmayıp, otel rezervasyon sisteminden etkilenen dış sisteme ait bir yazılımı temsil ediyor. Bunu aktörlerin UCleri kullanırken çizilen bağlantıların ok yönünden kestirebiliriz. UClerden etkilenen aktörlerde ok yönü UCden aktöre doğru iken normal kullanıcılarda aktörden UClere doğru bir geçiş olduğunu sizde farketmişsinizdir.
 
Diyagramdan da görüldüğü gibi otel rezervasyon sistemi Otel Giriş/Çıkış, Yeni Rezervasyon, Rezervasyon Değişilik gibi 3 ana UCden oluşmakta, diğer UCler ise ana UCler ile ilişkide bulunan alt UCler olarak adlandırılabilir.
 
İlişkiler
 
Kapsama (Include) ilişkisini, kendinizi 2 yada daha fazla UCde tekrar ediyor görüyorsanız, tekrar eden bölümleri ayrı bir UC olarak bölüp ve kapsama ilişkisini kullanmalısınız. Kapsama nesnelerdeki gibi tekrar kullanılabilir UCler yapmanıza olanak verir. Visio’da kapsamayı “uses” ilişkisi ile kullanabilirsiniz. Kapsanan alt UCler daha küçük ve tekrar kullanılan UClerdir. Örneğimizde bulunan Rezervasyon Değişiklik UC’i rezervasyon bulma ve rezervasyon iptal gibi 2 UC’i  kapsamaktadır (içermektedir). Bu 2 alt UC başka UCler tarafından da tekrar tekrar kullanılabilir.
 
Genelleme ilişkisini başarılı senaryo içinde bulunan alternatif yolları ayrı bir UC olarak belirtmek istediğinizde kullanabilirsiniz. Genelleme nesnelerdeki kalıtım mantığına uygun UCler üretmeniz için idealdir. “Rezervasyon Bulma” genellemenin yapıldığı bir UC’dir ve “İsme Göre” UC’i bu genel UC’e ek özellikler getirmiştir denilebilir.
 
Genişleme (Extend) ilişkisi genellemeden farklı olarak size kontrol edilebilir genişleme noktaları sağlar. Genellemeye 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. Örnekte  “Yeni Rezeryasyon” genel bir UC olup rezervasyon tipine göre bir genişleme noktası sunmuştur. Online ve Telefonla rezervasyonlar sadece bu genişleme noktasında ana UC’i genişletebilir ve ek getirebilirler. Visio da genişleme “extend“ ile belirtilmiştir.
 
İlişkiler konusunda farklı yaklaşımlar sergilenmektedir. Genel kabul görmüş yaklaşımda Use Case diyagramlarının mümkün olduğunca basit, sade ve az UC içermesi bunun yanında genelleme ve genişleme ilişkilerini kullanmaktan kaçınılması tavsiye edilmektedir. İhtiyacımız olan tek ilişki kapsama (include)’dır. 
 
Use Case Dökümantasyonu
 
UC diyagramları aslında sadece basit çöp adamlardan oluşan, sıradan çizimlerdir. Amatör analizciler diyagramlar üzerine eğilmekte, analizin en önemli noktası UC dökümantasyonunu es geçmektedirler. Bugün bir çok profesyonel analizlere baktığımızda diyagramların çok az hatta hiç olmadığı ama çok kaliteli UC dökümanlarının bulunduğu sistemlerle karşılaşmak doğaldır.  Fakat UC dökümantasyonunda bir standart yoktur. Aşağıda verilen örnek ihtiyaçlarınızı karşılayan en temel dökümantasyon formatı olmakla beraber, ihtiyaçlarınıza göre buraya ek alanlar ekleyebilirsiniz.
 
Kısaca dökümantasyonda yer alan bölümler şöyle özetlenebilir:
  • Adı: UC adı
  • Aktörler: UC ile etkileşimde olan aktörler
  • Ön Koşullar: UC’in başlayabilmesi için gerekli ön koşullar
  • Son Durum: UC başarı ile sonlandıktan sonra oluşan son durum, etkilenen sistemler, sistem yapılan değişiklikler vb.
  • 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 UC 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 UCler 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)
 
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ı: 8 – 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’leri Nasıl Kullanmalıyım?
 
Buraya kadar UC diyagramları, ilişkileri ve dökümantasonu üzerinde durduk, peki bu UC’leri nasıl ortaya çıkartırız ve kullanırken nelere dikkat etmeliyiz?
 
UC’ler müşteri ile yapılan toplantılar üzerine bina edilirler. Toplantınızın kalitesi analizin, dolayısıyla Use Case’lerin kalitesini belirler. Use Case’leri ortaya çıkarmak için standart bir yol olmamakla birlikte şu yolları izleyebilirsiniz.
  • Aktörleri bulmak için sistemde çok sık adı geçen özneler üzerine yoğunlaşın, Müşteri, Resepsiyon görevlisi, Rezervasyon görevlisi gibi. Özneleri çıkartırken rollerine göre gruplandırın ve aktör sayınızı en aza indirin
  • Use Case’ler için cümleler arasında geçen kilit fiiller üzerinde çalışın, fiillerin çok sık geçmesi ve bunların projenin ana hedeflerine uygun, sonunda sisteme değer katan iş süreçlerini içermesine dikkat edin
  • İlişkileri kullanırken daha çok kapsama (içerme) ilişkisi üzerine dikkatinizi verin, diğer ilişkileri kullanmaktan kaçının. Tekrar ettiğinizi düşündüğünüz senaryo adımlarını küçük UClere çevirip kapsama ilişkisini kullanın
  • Çok fazla UC kullanmaktan kaçının. Bugün büyük projelerde dahi 10 ila 20 arasında ana UC bulunur. Burada sıkça düşülen hata çok tanecikli, ufak ufak UC’ler kullanarak projenin ana hedefinden saparak detaylarında boğulmaktır. Şunu aklınızdan hiç çıkartmayın önemli olan sistemin detayları değil, analiz ettiğimiz sistemde geçen ve kullanıcılar için değer taşıyan çekirdek iş süreçlerini bulmaktır. Sistem için şu soruyu kendinize sorun, bu UC gerçekten benim iş hedeflerime uygun bir fayda sağlıyormu.
  • Use Case’ler ile sınıf tasarımları arasında doğrudan bir ilişki kurmaya çalışmayın fakat UC’lerinde bu noktada size ana sınıfları çıkarmanızda yardımcı olabileceğini ve ilerisinde sekans diyagramlarına geçişi kolaylaştıracağını unutmayın.
Görüldüğü üzere aslında Use Case’ler analiz aşamasında hayati önem taşıyorlar. Use Case’ler ile sistemi anlamaya çalışmak, dışarıdan bir gözlemci olarak sistemin size sunduğu hizmetleri ve süreçleri anlamak proje teknik ekipleri açısından hayati önem taşır. Başta gereksinimlerin doğru şekilde anlaşılması yapılan bu Use Case çalışmalarının Müşteri ile birebir yapılmasını ve paylaşılmasını gerektirir. Use case’ler ileride takıma dahil olabilecek programcıların sisteme daha kolay alışabilmesi ve müşteri kontratlarında Use Case’lerden yararlanabiliyor olmanız Use Case dökümantasyonunun önemini bir kat daha artırıyor.
 
Son olarak iyi Use Case analizi hayat kurtarır!
 
 
Referans:
 
UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, Martin Fowler, Addison Wesley, 2003


Not: Yazılar konusundaki yorumlarınız için lütfen Yorum Yazın bölümümüzü kullanın.

Yazar : Oğuz Bayram
Son Güncelleme : 26 Ekim 2005, Çarşamba
Sayfa Sürümü : 1
Okunma Adedi : 16,958
Son Okunma : 2017-05-27 03:53:39
Kaynaklar : http://www.yazilimmimarlari.com

Kötü Tasarımın BelirtileriUse Case Diyagramları İle Başarılı Proje AnaliziRSS Dosya Yapısı
© [Site Haritası]
| Makaleler | Seyir Defteri | Kaynaklar | İndirin | İletişim |

RSS dosyasını görmek için tıklayınız. RSS dosyasını görmek için tıklayınız.XML versiyonu için tıklayınız WAP versiyonu için tıklayınız Bu site DyNA İçerik Yönetim Sistemi üzerinde çalışmaktadır.
İsmail KIRBAŞ ile Tasarım Yolculuğu Anasayfa İsmail KIRBAŞ ile Tasarım Yolculuğu Anasayfa İsmail KIRBAŞ ile Tasarım Yolculuğu Anasayfa
ismail kırbaş ile web sitesi tasarimi sitemap ismail kırbaş ile web sitesi tasarimi sitemap
  Sitemizde 2 kişi çevirimiçi | Bugün =53 | Dün =285 | Bu Ay=5,749 | Günlük En Fazla=1,109 tekil ziyaretçi