nesne yönelimli programlama – hafta # 5

NESNE YÖNELİMLİ PROGRAMLAMA – HAFTA # 5
Yrd.Doç.Dr.Hacer Karacan
2
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
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.
4
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.
5
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ıdanaş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.
6
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
gerçekleştirmek için de yeni sınıflar tasarlamak gerekebilir.
sınıfları
7
Ö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.
8
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.
9
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.
10
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.
11
UP – Temel Özellikler
12
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.
13
Yinelemeli Sürecin Yararları
14
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.
15
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ı
16
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ı.
17
Tümleştirilmiş Süreçte (UP) Yazılım Projesi Aşamaları
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.
Birincil Aktör ve Sistemin Sınırları
Birincil Aktör ve Sistemin Sınırları
Birincil Aktör ve Sistemin Sınırları
Birincil Aktör ve Sistemin Sınırları
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
Uzantılar (Alternatif Akışlar):
• *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
Uzantılar (Alternatif Akışlar):
• 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
Uzantılar (Alternatif Akışlar):
• 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
Uzantılar (Alternatif Akışlar):
• 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
diyagramları ile belirtilir:
▫ Gerçek dünyadaki kavramsal
sınıfları/nesneleri değil!)
aşağıdaki
sınıflar
bilgileri
ve
nesneler
▫ Sınıflar arasındaki ilişkiler (bağlantılar - association),
▫ Sınıfların nitelikleri (attributes)
içeren
sınıf
(Yazılım
Ö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ı
(conceptual class) belirlenmesi oluşturur.
kavramsal
sınıfların
• 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
Gereksiz Sınıfların Elenmesi
Gereksiz Sınıfların Elenmesi
Gereksiz Sınıfların Elenmesi
Gereksiz Sınıfların Elenmesi
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
(associations) belirlenir.
sınıflar
arasındaki
bağlantılar
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
kullanılmaktadır.
Baba
-
kardeş
yerine
Amca
ilişkisi
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