NESNE YÖNELİMLİ PROGRAMLAMA – HAFTA # 5 · Kullanım Diyagramları (Use Case Diagram) •Kullanım senaryoları sadece düz metin ( text ) olarak değil, istendiğinde metin

NESNE YÖNELİMLİ PROGRAMLAMA – HAFTA # 5

Yrd.Doç.Dr.Hacer Karacan

Modelleme

• Gerçekleştirilmesi maliyetli ya da riskli olan projelerde, projenin beklenmedik durumlardan dolayı başarısızlığa uğramaması için bir takım fikir ve tasarım işlemleri (modelleme) yapılır.

• Modelleme fikir bazındaki projenin, gerçek dünyada uygulanabilirliğini sorgular.

• Karşılaşılabilecek sorunlara önceden çözüm bularak işgücü, maliyet, zaman gibi kaynak kayıplarını önler.

• Nesneye yönelimli programlamayla birlikte modellemeye duyulan ihtiyaç artmış ve Yazılım projelerinde kullanılmak üzere UML (Unified Modeling Language) modelleme dili geliştirilmiştir.

• Model oluşturmak şu getirileri sağlar

▫ Yapılacak iş için gereksinimleri ortaya koyar

▫ Anlaşmazlıkları çözümlemeye yardımcı olur.

▫ Yanlışları Önler

2

Giriş

• Problem domeninin yani gerçek dünyanın modelinin oluşturulması, problemi daha iyi anlayabilmek için problemin kağıt üstünde bir resminin oluşturulması anlamına gelir.

• Bu modeli oluşturmak problemin çözümlenmesi (analysis) aşamasını oluşturur.

▫ Bu nedenle bu aşamada problemi çözmek için değil anlamak için çaba gösterilir.

• Problemi çözmek ise tasarım aşamasının konusudur.

Prosedürel Tasarım

• Yapısal programlama yaklaşımında,

▫ ilk tasarım adımı programdan beklenen işlevselliği belirlemek

Yanıtlanması gereken soru “Bu program ne yapacak?”

▫ İkinci adım istenileni gerçekleştirmesi için programın atması gereken temel adımları yüksek-düzeyli “pseudo” kodlar ya da akış diyagramları yardımıyla belirlemek

▫ Son olarak her temel adım daha küçük adımlara bölünerek tasarımı daha rafine hale getirmek

• Bu yaklaşıma, prosedürel ayrıştırma (procedural decomposition) denir.

4

Nesne-yönelimli Tasarım

• Prosedürel yaklaşımdan köklü olarak ayrılır.

• Nesneye-yönelik yaklaşımda problem,

▫ İşlemlere yada veri yapılarına bölünmez;

▫ Birbirleriyle etkileşen bir nesneler sistemi olarak analiz edilir.

• Ayrıca, prosedürel yaklaşım yukarıdan-aşağıya işleyen bir analiz tekniği olmasına rağmen, nesneye yönelik yaklaşım yukarıdan-aşağıya analiz ve aşağıdan-yukarıya sentez tekniklerini birleştirir.

• Nesneye-yönelik tasarım (“iterative” tarzda) şunların yapılmasını gerektirir:

▫ Sınıfların belirlenmesi,

▫ Özelliklerin ve davranışların tespiti,

▫ Sınıflar arası ilişkilerin bulunması ve

▫ Sınıfların bir hiyerarşi içinde organize edilmesi.

5

Sınıfların Belirlenmesi

• Nesneye-yönelik tasarımda ilk adım programın ihtiyaç duyacağı sınıfların belirlenmesidir.

• Bunun için kullanılabilecek basit bir teknik: ▫ programdan beklenenin doğal dil ile betimlenmesi ▫ betimleme içindeki isimlerin listelenmesi ▫ bu liste içinde sınıfların seçilmesi

• kavramsal nesneler yada olaylar veya etkileşimler söz konusu olduğunda sınıfların belirlenmesi zorlaşabilir.

• Problem modeli içindeki elemanlara karşılık gelen sınıfları gerçekleştirmek için de yeni sınıflar tasarlamak gerekebilir.

6

Özelliklerin Ve Davranışların Tespiti

• Bir sınıfın sorumlulukları iki alanda ortaya çıkar:

▫ Taşıması gereken bilgiler

▫ Sınıfa ait bir nesnenin neler yapabileceği yada bu nesneye neler yapılabileceği.

• Her sınıf kendisini betimleyen bazı özelliklere sahiptir. Sınıfa ait bir nesnenin özellik değerleri nesnenin içinde bulunduğu durumu (“state”) belirler.

• Her sınıf, ayrıca, nesnelerin diğer nesnelerle nasıl etkileştiğine ve bu etkileşim neticesinde içinde bulundukları durumların nasıl değiştiğine karşılık gelen davranışlara sahiptir.

7

Sınıflar Arası İlişkilerin Bulunması

• Sınıfların bir kısmı yalıtılmış halde bulunabilirken, büyük bir çoğunluğu diğerleriyle işbirliği ve bağımlılık ilişkisi içindedirler.

• Bir sınıf bir diğerine çeşitli şekillerde bağımlı olabilir:

▫ Diğer bir sınıfın eleman fonksiyonlarını kullanması gerekebilir;

▫ Diğer bir sınıf kendi içine gömülmüş olabilir;

▫ Sınıfın arayüzü bir diğer sınıfa bağımlı olabilir vs.

• Sınıflar arası ilişkileri belirlerken sınıfların davranışlarını yerine getirirken, birbirlerinin bilgilerini ve davranışlarını kullanıp kullanmadıklarına bakılır.

8

Sınıfların Bir Hiyerarşi İçinde Organize Edilmesi

• Sınıfların özelliklerini ve davranışlarını tespit ederek, aralarındaki benzerlik ve farkları daha iyi görürüz; ayrıca, sınıflar arası ilişkileri bularak da hangi sınıfların diğerlerinin işlevselliğine bağımlı olduğunu açığa çıkarırız.

• Bir sınıfın farklı kategorilerinin tespiti, bir hiyerarşi için yeterli koşulu oluşturmaz. Gerekli koşul farklı kategorilere farklı işlemlerin yapılacak olmasıdır.

9

TÜMLEŞTİRİLMİŞ YAZILIM GELİŞTİRME SÜRECİ

(THE UNİFİED PROCESS - UP)

• Gerekli kalite kriterlerini sağlamak için yazılım projelerini uygun şekilde planlamak ve belli bir disiplin altında bu plana uymak gerekir.

• Yazılımcılara planlama konusunda yol gösteren çeşitli yazılım geliştirme süreçleri oluşturulmuştur.

▫ Örn. Spiral, çağlayan (waterfall), vb.

• Nesneye dayalı yazılım geliştirmek için var olan yöntemlerin deneyimler sonucu kabul gören en iyi özellikleri bir araya getirilerek tümleştirilmiş yazılım geliştirme süreci (The Unified Process - UP) oluşturulmuştur.

10

UP – Temel Özellikler

11

UP: Yinelemeli ve evrimsel yazılım geliştirme

• Her yineleme (iterasyon) adımında bütün bir yazılım projesi varmış gibi davranılır.

• Gerekli tüm aşamalardan geçilerek sınanmış, çalışır bir ürün elde edilir.

12

Yinelemeli Sürecin Yararları

13

UP'nin Kullanılmasına Yönelik Öneriler

• 2 - 6 haftalık sabit süreli iterasyonlar uygulanmalı ▫ Deneyemlere göre bir iterasyonun süresinin 3 ya da 4 hafta olarak

seçilmesi iyi sonuçlar vermektedir. ▫ İterasyon 2 haftadan kısa olursa bu sürede bir ürün çıkarmak

mümkün olmaz. ▫ Altı haftadan daha uzun süreli iterasyonlarda ise erken geri besleme

alma olanağı ortadan kalkar ve çok fazla sayıda istek ile uğraşmak gerekir.

• Yüksek risk taşıyan kısımlar ilk iterasyonlarda gerçeklenmeli

▫ Daha önce de açıklandığı gibi ortaya çıkabilecek problemleri mümkün olduğu kadar erken fark edip bunlara karşı önlem alabilmek için zorlu görünen istekler önce ele alınmalı.

• Temel oluşturan yapılar (çekirdek) önce gerçeklenmeli

▫ Yüksek riskli kısımlardan başka önce ele alınması gereken modüller sistemin temelini (iskeletini) oluşturan yapılardır.

14

UP'nin Kullanılmasına Yönelik Öneriler

• Sürekli kullanıcılardan geri besleme alınmalı, isteklere uyulmaya dikkat edilmeli

• Her iterasyondan sonra ürün tam olarak sınanmalı ▫ Her iterasyonda bir ürün oluşturulduğu unutulmamalı ve bu ürün tam

olarak sınanmalıdır. Aksi durumda hatalar geç fark edilir ve bunları düzeltme maliyeti

yüksek olur.

• Kullanım senaryoları yöntemi (use case) uygulanmalı

• Görsel modelleme (UML) kullanılmalı

▫ UML tasarımların ifade edilmesini ve takım elemanları arasında iletişimi kolaylaştırır.

• Bir iterasyonda elde edilen deneyim diğer iterasyonda kullanılmalı

15

Tümleştirilmiş Süreçte (UP) Yazılım Projesi Aşamaları

▫ Başlangıç (Inception): Bu aşamada kabaca projenin vizyonu ortaya konur. İstekler ayrıntıya girilmeden genel olarak ele alınır ve fizibilite değerlendirmesi yapılır. Bu aşama sonunda projeye girip girmemeye karar verilir.

▫ Ayrıntılandırma (Elaboration): Bu aşamada daha gerçekçi çözümleme yapılır ve istekler ayrıntılı olarak ele alınır. Çekirdek yapı ve yüksek riskli kısımlar yinelemeli olarak bu aşamada oluşturulur.

▫ Tamamlama (Construction): Daha az riskli ve düşük öncelikli kısımların yinelemeli olarak gerçeklenmesi.

▫ Yayım (Transition): Beta testleri, piyasaya sürme çalışmaları.

16

Tümleştirilmiş Süreçte (UP) Yazılım Projesi Aşamaları

17

Kullanım Senaryolarının (Use-Cases) Tanımı

• Kullanım senaryoları, isteklerin anlaşılmasını ve ifade edilmesini sağlayan bir yöntemdir.

• Özellikle işlevsel isteklerin ifade edilmesinde kullanılır.

• Fikir ilk olarak Ericsson' da çalışan Ivar Jacobson adlı İsveçli bir mühendis tarafından oluşturulmuştur. Daha sonra Rational' de çalışmıştır, şimdi kendi firmasındadır.

Senaryo

• Anlamlı bir sonuca (amaca) ulaşmak için aktör ile sistem arasında gerçekleşen olayların belli bir zinciridir.

• Bir sistemin çalışması sırasında birden fazla senaryo gerçekleşebilir.

• Olası tüm senaryolar kullanım senaryolarını (use case) oluştururlar.

Senaryo 1 - a

Senaryo 1 - b

Senaryo 1 - c

Senaryo 1 - d

Senaryo 1 - e

Senaryo 2 - a

Senaryo 2 - b

Senaryo 2 - c

Senaryo 2 - d

Kullanım senaryoları

• Yazılım dünyasındaki önemli isimleri kullanım senaryoları ile ilgili orijinal tanımları aşağıda verilmiştir:

• (Jacobson, Booch &Rumbaugh, 1999):

▫ “Bir Kullanım Senaryosu, bir sistemin gerçekleştirdiği ve belirli bir aktör için gözlemlenebilir bir sonuç ortaya çıkaran ve çeşitli varyasyonlar içeren eylemler serisini ifade eder."

• (Cockburn, 2000):

▫ “Bir Kullanım Senaryosu, tasarlama aşamasındaki bir sistem ve harici aktörler arasında belirli bir hedefe yönelik gelişen olası etkileşim serilerinin koleksiyonudur. “

• Bu konu ile ilgili ayrıntılı bilgi aşağıdaki kaynaklarda bulunabilir.

▫ http://www.rational.com/uml/

▫ http://alistair.cockburn.us/usecases/usecases.html

▫ http://www.pols.co.uk/use-case-zone/

▫ http://www.mcs.vuw.ac.nz/research/object/Papers/euc-html/

Aktör

Birincil Aktör ve Sistemin Sınırları

• Üzerinde çalıştığımız sistemi hangi düzeyde incelediğimize ve sınırlarını ne şekilde çizdiğimize bağlı olarak birincil aktörler değişiklik gösterir.

• Kullanım senaryolarını yazarken sistemin sınırlarını doğru olarak belirlemek, nelerin dışarıda nelerin içeride olacağına doğru karar vermek gerekir.





Kullanım Senaryolarının Yazılması

▫ İhtiyaçların ve istenen özelliklerin listelenmesi şeklinde DEĞİL.

▫ Sistem kara kutu olarak ele alınır. Sistemin iç yapısı görülmez, sistemin dışarıya (aktörlere) karşı sorumlulukları ifade edilir.

▫ Aktörler ile sistem arasındaki etkileşim etken cümleler ile ifade edilir.

▫ "Ne yapar?" sorusu cevaplanır, "Nasıl yapar?" değil.

Sistemin sorumluluklarını nasıl yerine getireceği daha sonra gelinecek olan tasarım aşamasında ele alınacak problemdir. Kullanım senaryolarını yazdığımız şimdiki aşamada ise sadece istekler anlaşılmaya çalışılıyor.

▫ Sistemin bitmiş hali hayal edilerek bu sistem çalıştığında oluşabilecek senaryolar yazılır.

Kullanım Senaryolarında Yer Alan Bölümler

• Her kullanım senaryoları grubunun (use case) bir adı ve numarası vardır. İsimden sonra şağıdaki bölümler gelir.

Önsöz (Preface) Bölümü

Önsöz (Preface) Bölümü

Birincil aktör, destek aktörü ve diğer aktörlerin belirlenmesi sistemin sınırlarını çizer.

Kullanım senaryoları ilgililerin (aktörlerin) tüm beklentilerini karşılayan tüm olayları ve sadece onları içerir.

Tüm ilgililerin ve beklentilerin ilk başta belirlenmesi önemlidir.

Aksi durumda senaryolarda bazı durumlar unutulabilir ve bu eksiklik ancak ileriki aşamalarda anlaşılabilir.

Ana Başarılı Senaryo (Temel Akış) Bölümü

Uzantılar (Alternatif Akışlar) Bölümü

Diğer Bölümler

• Sıra Dışı Durumlar Bölümü (Exceptions) :

▫ Sistemde hatalar oluştuğunda yapılacaklar sıralanır. Bazı tasarımcılar bu bölümdeki olayları da uzantılar bölümünde ele alırlar.

• Özel İstekler Bölümü (Special Requirements) :

▫ İşlevler ile ilgili olmayan istekler bu bölümde belirtilir. Bu istekler genellikle hız, güvenilirlik, rahat kullanım gibi kalite kriterlerine yöneliktir.

• Teknolojik Beklentiler Bölümü :

▫ Kullanıcıların ön gördükleri donanım özellikleri burada sıralanır. Örneğin giriş/çıkış işlemlerinin hangi cihazlar ile yapılması istendiği bu bölüme yazılır.

Örnek

Senaryo Grubu (Use Case) SG1: Satış İşlemleri

▫ Konu: Market Sistemi

▫ Birincil Aktör: Kasa Görevlisi

▫ İlgililer (Aktörler) ve Beklentileri (Stakeholders and Interests):

Kasa Görevlisi: Bilgilerin doğru ve hızlı girilmesi, toplamın doğru

hesaplanması, para üstünün doğru hesaplanması

Satış Elemanı: Komisyonun doğru hesaplanması ve kayıt edilmesi

Müdür: Yetkili işlemleri (kasa görevlisinin yapamadığı) kolaylıkla yapabilmek

Vergi Dairesi: Vergilerin doğru hesaplanabilmesi ve toplanabilmesi

Kredi Kartı Asıllama Merkezi: Ödeme bilgilerinin doğru formatta gelmesi ve asıllama bilgilerinin kayıt edilmesi

Örnek

Senaryo Grubu (Use Case) SG1: Satış İşlemleri

▫ Ön Koşullar (Preconditions):

Kasa görevlisi sisteme giriş yapmıştır.

▫ Son Koşullar (Postconditions):

Satış bilgileri kayıt edilmiştir.

Vergi doğru olarak hesaplanmıştır.

Muhasebe ve envanter kayıtları güncellenmiştir.

Komisyon kayıt edilmiştir.

Fatura oluşturulmuştur.

Kredi kartı onayı kayıt edilmiştir.

Örnek

Ana Başarılı Senaryo (Doğal Akış)

Örnek

Uzantılar (Alternatif Akışlar):

• *a. Herhangi bir anda müdür yetkili bir işlem yapmak ister ve şifresini girer:

1.Sistem müdür-yetkisi konumuna geçer.

2.Müdür yetkili bir işlem gerçekleştirir. Örneğin satışı iptal eder, bir ürünün fiyatını indirir vs.

3.Müdür sistemden çıkar.

4.Sistem normal konuma (kasa görevlisi yetkisi) geçer.

Örnek


• *b. Herhangi bir anda sistemde bir hata oluşur:

▫ Bu durumlarda bilgilerin kayıt edilmesi ve sistemin kaldığı yerden devam edebilmesi istenir.

▫ 1. Kasa görevlisi sistemi yeniden başlatır, sisteme giriş yapar ve sistemin önceki durumdan devam etmesini ister.

▫ 2. Sistem önceki durumu oluşturur.

2a. Sistem önceki durumu oluştururken anormallik sezer.

1. Sistem hata uyarısı verir, hatayı kayıt eder ve temiz (başlangıç) duruma geçer.

2. Kasa görevlisi yeni bir satış başlatır.

Örnek


• 3a. Geçersiz bir ürün kodu (Sistemde bulunamadı):

▫ 1. Sistem hata uyarısı verir, ürünü reddeder. 2. Kasa görevlisi hataya tepki verir:

2a. Ürünün üstünde okunabilir bir kod vardır:

1. Kasa görevlisi kodu sisteme elle (manual) girer.

2. Sistem ürünün tanıtıcı bilgisini ve fiyatını gösterir.

2b. Ürünün üstünde kod yoktur, ama fiyatı yazılıdır:

1. Kasa görevlisi müdürden yetkili bir işlem yapmasını ister.

2. Müdür şifresini girer.

3. Kasa görevlisi fiyatı elle girer.

Örnek


• 3b. Aynı üründen bir taneden fazla alınmıştır (5 şişe içecek):

▫ 1. Kasa görevlisi ürün kodunu ve adetini sisteme girer.

• 3-6a. Müşteri kasa görevlisine bir ürünü almaktan vazgeçtiğini söyler:

▫ 1. Kasa görevlisi satıştan çıkarılacak ürünün kodunu sisteme girer.

▫ 2. Sistem ürünü satıştan çıkarır ve geçerli toplamı gösterir.

• 3-6b. Müşteri alışverişten vazgeçtiğini söyler:

▫ 1. Kasa görevlisi satışı iptal eder.

Örnek


• 5. Müşteri indirim hakkı olduğunu söyler (müşteri kartına sahiptir):

▫ 1. Kasa görevlisi müşteri kodunu sisteme girer.

▫ 2. Sistem indirimi uygular ve yeni toplamı gösterir.

• 7a. Nakit ödeme:

▫ 1. Kasa görevlisi ödenen nakit miktarı sisteme girer.

▫ 2. Sistem para üstünü gösterir ve para çekmecesini açar.

▫ 3. Kasa görevlisi müşteriden ödemeyi alır ve para üstünü verir.

▫ 4. Sistem nakit ödemeyi kayıt eder.

• 7b. Kredi kartı ile ödeme:

▫ 1. ....

• 7c. Çek ile ödeme:

▫ 1. ....

Örnek

Özel İstekler (Special Requirements):

• Düz kare monitör. Yazılar 1 metre uzaklıktan okunabilmeli.

• Kredi kartı sorgulamasının cevabı en geç 30 saniyede gelmeli.

• ....

Örnek

Teknolojik Beklentiler (Technology Variations List):

• *a. Müdür kendisini sisteme bir kart okutarak ya da tuş takımından şifresini girerek tanıtır.

▫ 3a. Ürün kodları bir barkod okuyucu ile veya tuş takımından elle girilebilir.

▫ 7b. Kredi kartı bilgiler kart okuyucu ile veya tuş takımından elle girilebilir.

▫ ....

Örnek

Açık noktalar (Open Issues):

• Vergi kanunlarındaki değişim sistemi nasıl etkiler?

• Kasa görevlisi mesaisi bittiğinde sistemden çıkarken para çekmecesini de almalı mı?

• Müşteri kart okuyucuları doğrudan kendisi kullanabilir mi, yoksa kasa görevlisi ile mi sisteme erişmeli?

• ....

Kullanım Diyagramları (Use Case Diagram)

• Kullanım senaryoları sadece düz metin (text) olarak değil, istendiğinde metin yerine UML diyagramı olarak da ifade edilebilirler.

• Kullanım diyagramlarında, kullanım senaryolarının aktörler ile ve kendi aralarındaki ilişkileri grafik olarak gösterilir.

• Bir sistemin içinde bir çok senaryo grubu bulunabilmekte ve değişik aktörler değişik senaryo grupları ile ilişkili olabilmektedir.

• Ayrıca senaryoların kendi aralarında da içerme (include) ve genişletme (extend) ilişkileri bulunabilmektedir.

İçerme vs. Genişletme

Kullanım Durumu Diyagramları

(Use Case Diagram)

Örnek:

Öğrenci otomasyon sistemine ilişkin kullanım diyagramı

Etkileşim Diyagramı

(Interaction Diagram)

• Kullanım diyagramları sadece istemde hangi senaryo gruplarının ve hangi aktörlerin yer aldığını gösterir.

• Aktörler ile sistem arasına geçen olayları yani senaryoların adımlarını göstermek için etkileşim diyagramları (interaction diagram) çizilir.

• Senaryoları ifade ederken aynı anda hem metin tipi senaryo yazımına hem de UML ile kullanım diyagramlarını ve etkileşim diyagramlarını çizmeye gerek yoktur.

• Senaryoları belirtmek için metin tipi yazım ya da diyagram gösteriminden biri tercih edilir.

Örnek:

Market sistemi etkileşim diyagramı

Kullanım Senaryolarının Yazılması

Kullanım Senaryoları - Diğer Sorular

• Bazı davranışlar aktörlerden yola çıkarak belirlenemeyebilir. Bu durumda aşağıdaki soruları da sormakta yarar vardır:

▫ Sistemin gerek duyduğu girişler ve çıkışlar nelerdir?

▫ Sistem hangi dış olaylardan etkilenir?

▫ Şu andaki sistemin (eğer firmada aynı iş için kullanılan eski bir sistem varsa) eksikleri ve problemleri nelerdir?

▫ Periyodik olarak gerçekleştirilen işler var mı?

• İsteklerin çözümlenmesinde (modellenmesinde) oluşturulan kullanım senaryoları (use case) nesneye dayalı özellikler taşımaz.

▫ Uygulama domeninin modellenmesinde ise nesneye dayalı

yöntem kullanılacaktır.

• Uygulama domeninin modelinde gerçek dünyayı (yani tasarlanacak olan sistemi) oluşturan kavramsal sınıflar ve nesneler yar alır.

▫ Bu model oluşturulurken yazılım sınıfları (çözüm) düşünülmez,

çünkü bu aşamada henüz program yazılmıyor.

• Model UML kullanılarak görsel hale getirilir.

• Uygulama domeninin modeli aşağıdaki bilgileri içeren sınıf diyagramları ile belirtilir:

▫ Gerçek dünyadaki kavramsal sınıflar ve nesneler (Yazılım sınıfları/nesneleri değil!)

▫ Sınıflar arasındaki ilişkiler (bağlantılar - association),

▫ Sınıfların nitelikleri (attributes)

Örnek

Market sistemi sınıf diyagramı

Kavramsal Sınıfların Belirlenmesi

• Kavramsal sınıflar gerçek dünyadaki somut ve soyut varlıklara karşı düşen sınıflardır. Örneğin; öğretmen, öğrenci, ders, işçi, banka hesabı, para, satış vb.

• Çözümlemenin (analiz) ilk aşamasını kavramsal sınıfların (conceptual class) belirlenmesi oluşturur.

• En çok kullanılan iki temel yöntem:

1. Kavramsal sınıfların kategori listesinden yararlanma

2. Kullanım senaryolarındaki isimlerden (isim tamlamalarından) yararlanmak

• İki yöntem birlikte de kullanılabilir.

Kavramsal Sınıfların Kategorileri

Kavramsal Sınıfların İsimler Yardımıyla

Belirlenmesi

• Kavramsal sınıfların belirlenmesinde kullanılan ikinci yöntem ise senaryolarda ve problemin tanımında yer alan isim ve isim tamlamalarından yararlanılmasıdır.

• Kullanım senaryolarında yer alan tüm isimler ve isim tamlamaları işaretlenir.

• Çoğunlukla ilk aşamada gereğinden fazla sınıf elde edilir. Daha sonra uygulanan eleme yöntemi ile gereksiz sınıflar ayıklanır.

Örnek

SG1 numaralı "Satış İşlemleri" senaryo grubu

Gereksiz Sınıfların Elenmesi






Problem Domeni Modelini Oluşturmada

Haritacı (Mapmaker) Yöntemi

Örnek

Market Sistemine Ait Kavramsal Sınıflar

Bu sınıflar belirlendiğinde çözümlemenin (analiz) ilk adımı tamamlanmış olur. Bundan sonra kavramsal sınıflar arasındaki bağlantıların (ilişkilerin) ve sınıfların niteliklerinin belirlenmesi gerekir.

Betimleme Sınıflarına Gerek Duyulması

• Dükkanda satılan malzemelerle ilgili fiyat, tip numarası gibi bilgilerin o malzemeye ilişkin nesnelerde tutulması (nitelik olduğu) öngörülebilir.

• Ancak dükkandaki o cinsten tüm malzeme satıldığında (nesneler yok olduğunda) o malzemeyle ilgili bilgiler de kaybolur.

• Böyle sistemlerde bir nesneyi betimleyen bilgilerin başka sınıflarda tutulması gerekir.

Betimleme Sınıfları Ne Zaman gereklidir?

• Bir malzeme ya da hizmetle ilgili bilgilere o malzeme ya da hizmetin var olup olmamasından bağımsız olarak erişmek gerekli ise,

• Bir nesnenin yok edilmesi bilgi kaybına neden oluyorsa,

• Gereksiz bilgi tekrarını önlüyorsa.

Kavramsal Sınıflar Arasındaki Bağlantıların

Belirlenmesi

• Uygulama domeninin modeli oluşturulurken ilk aşamada kavramsal sınıflar bulunur.

• İkinci aşamada ise bu sınıflar arasındaki bağlantılar (associations) belirlenir.

Bağlantıların UML Diyagramlarında Gösterilmesi

Çoğullama (multipicity) Sayısı

• Çoğullama sayısı o sınıftan kaç tane nesnenin, diğer sınıftan kaç tane nesne ile belli bir anda geçerli olarak ilişkilendirilebileceğini gösterir.

• Çoğullama sayısı, modeli nasıl kullanacağımıza bağlıdır.

▫ Aşağıdaki örnekte bir malın tükenip depoda bulunmaması bizi ilgilendiriyorsa Depo ucuna ait çoğullama sayısı 0..1 olabilir. Aksi durumda bu sayının 1 olması yazılım açısından daha uygundur.

Çoğullama Sayılarının Yazılması

Bağlantıların Bulunmasına İlişkin Yöntemler

• Bu konuda da değişik yöntemler kullanılmaktadır:

▫ Yaygın Bağlantılar Listesi (Common Associations List)

▫ Kullanım senaryolarındaki fiillerden yararlanmak.

Yaygın Bağlantılar Listesi

(Common Associations List)

• Bu yöntemde, kavramsala sınıflar arasında şu ilişkilerin varlığı aranır:

Yaygın Bağlantılar Listesi

(Common Associations List)

• Bu yöntemde, iki kavram arasındaki ilişkiye ait bilgi belli bir süre sistem tarafından bilinmesi gerekiyorsa (need-to-know association) göz önüne alınır.

• İki kavram arasındaki ilişki tasarlanan sistem açısından gerekli değilse dikkate alınmaz. Örneğin Satış - Müdür bağlantısı gerekli olmayabilir.

Kullanım Senaryolarındaki Fiillerden Yararlanmak

• Diğer yöntemde ise kullanım senaryolarındaki fiiller dikkate alınarak tüm olası bağlantılar (ilişkiler) listelenir.

• Aşağıdaki maddeler dikkate alınarak gereksiz bağlantılar ayıklanır:

Kullanım Senaryolarındaki Fiillerden Yararlanmak

• Örnek:

▫ "Satış dükkanda gerçekleşir" ilişkisi, "satış terminalde yapılır" ve "terminal dükkanda bulunur" ilişkilerinden türetilebilir.

▫ Genellikle UML diyagramında iki sınıf arasında birden fazla yol varsa, çözümlemede fazlalık (türetilebilir) ilişkiler olduğu düşünülebilir.

▫ Her türetilebilir ilişkinin elenmesi doğru değildir. Sistem açısından önemli olanlar kalabilir.

Örneğin toplumda Baba - kardeş yerine Amca ilişkisi kullanılmaktadır.

Bağlantıların Bulunmasına İlişkin Öneriler

• Sistemin tasarımını ilgilendiren bağlantılara (need-to-know) yoğunlaşmak gerekir.

• Bağlantılara doğru isimler atanmalı. Tip adı - fiil - tip adı

• Bağlantının adı sadece bir ya da bir kaç işlemin adı değil bir ilişkinin ifadesi olmalıdır.

Bağlantıların Bulunmasına İlişkin Öneriler

• Gerekli olan yerlere rol adları da yazılmalıdır. Roller bağlantının iki ucunu oluştururlar.

• Sahip olma, oluşma (aggregation, compositon) ilişkilerini ayrıntılı olarak belirlemek bu aşamada gereksizdir.

• Bu aşamada bazı bağlantıların unutulması sistem tasarımını çok etkilemez.

• Kavramsal sınıfların doğru olarak belirlenmesi bağlantılardan daha önemlidir.

• Gereğinden fazla bağlantı modelin anlaşılırlığını azaltabilir.

Örnek

Market Sisteminin UML Sınıf Diyagramı

Kavramsal Sınıfların Niteliklerinin (Attributes)

Belirlenmesi

• Bir sınıfın nitelikleri, o sınıftan nesneler yaratıldığında nesnelere özgü değerler alabilen verilerdir.

• Bu aşamada amaç, üzerinde çalışılan senaryoları ilgilendiren nitelikler bulmaktır.

• Nitelikler genellikle basit veri tipleri (int, string, bool, date) ifade edilirler.

• Eğer bu aşamada nitelik olarak düşünülen veri daha karmaşık bir tipte ise o verinin bir bağlantı ya da ayrı bir sınıf olma olasılığı yüksektir.

Kavramsal Sınıfların Niteliklerinin (Attributes)

Belirlenmesi

• Aşağıda gösterilen örnekte Terminal, Kasa Görevlisi tarafından kullanılan bir varlıktır ama onun niteliği değildir.

Karmaşık Niteliklerin Gösterilmesi

• Bazı durumlarda nitelikler basit veri tiplerinden oluşmazlar.

• Eğer bir nitelikte aşağıdaki özellikler varsa başka bir sınıf ile ifade edilmesi doğru olur.

▫ Birden fazla alandan oluşuyorsa: Telefon no, ad/soyad

▫ Üzerinde işlem yapılıyorsa: Kredi kartı numarası onaylanması

▫ Kendi nitelikleri varsa: Fiyatın geçerlilik tarihi olabilir.

Karmaşık Niteliklerin Gösterilmesi

• Bu tip nitelikler aşağıda gösterildiği gibi iki farklı şekilde de ifade edilebilir.

Birimleri Olan Niteliklerin Gösterilmesi

• Birimleri olan büyüklükleri de basit veri tipleri ile göstermek doğru olmaz. Örneğin şekilde gösterildiği gibi satışın tutarını sadece sayı olarak ifade etmek yarar sağlamaz. Bunun yerine bilinen bir veri tipi olan Para kullanılabilir.

Niteliklerin Özelliklerinin Gösterilmesi

• Eğer çözümleme (analiz) sırasında kavramsal sınıfların özellikleri hakkında daha fazla bilgi elde edilmişse bunlar da diyagramlar da belirtilir.

• Örneğin niteliklere ilişkin erişim hakları diyagramlarda gösterilebilir. "+" simgesi bir niteliğin açık (public), "-" simgesi ise özel (private) oldupunu belirtir.

• "/" simgesi ise bir niteliğin diğer niteliklerden türetilebilen (elde edilebilen) (derived) bir nitelik olduğunu belirtir.

Niteliklerin Özelliklerinin Gösterilmesi

Analiz aşamasında elde edilen sınıflar sadece problemdeki kavramların resmidir, yazılım sınıfları değillerdir. Tasarım aşamasında yazılım sınıfları oluşturulurken kavramsal sınıflar kaynak olarak kullanılacaktır. Örnek Market sistemine ilişkin uygulama domeni modelinin bir kısmı yanda UML sınıf diyagramı şeklinde gösterilmiştir.

Kaynaklar

• Y.Doç.Dr.Feza BUZLUCA ders notları

http://www.buzluca.info/dersler.html




NESNE YÖNELİMLİ PROGRAMLAMA – HAFTA # 5 · Kullanım Diyagramları (Use Case Diagram) •Kullanım senaryoları sadece düz metin ( text ) olarak değil, istendiğinde metin

Documents