TBML-205

Nesnesel Analiz
ve
Tasarım

Object Oriented Analysis

And
Design (OOA/D)
Hazıralayan:
Doç. Dr. Nuri Murat YAĞMURLU

24.11.23 1
 3.4. 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. Şekil 3.2' de kullanım diyagramlarının genel yapısı
gösterilmiştir.
Şekilde de görüldüğü gibi 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. Bu ilişkilerin anlamları aşağıda açıklanmıştır:

24.11.23 2
 Şekil 3.2' de de görüldüğü gibi 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

24.11.23 3
3.4.1. Örnek

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

Şekil 3.3' te örnek olarak bir öğrenci otomasyon sisteminin bir kısmına ait kullanım diyagramı
gösterilmiştir.
Örnek istemin içinde dört adet senaryo grubu bulunmaktadır:
•Sisteme giriş
•Derse kayıt
•Geç kayıt
•Sınıf listesi göster
Bu senaryo gruplarının arasında çeşitli ilişkiler geçerlidir. Örneğin derse kayıt ve sınıf
listesini göster senaryoları sisteme giriş senaryosunu içermektedir. Çünkü derse kayıt
senaryoları yürütülürken sisteme giriş senaryosunun de yürütülmesi gereklidir.
Diğer taraftan geç kayıt senaryosu derse kayıt senaryosunu genişletmektedir. Normal işlemler
derse kayıt senaryolarında belirtilmektedir. Eğer öğrenci belirtilen sürede kayıt olmamışsa geç
kayıt senaryosuna geçilmektedir.
Ayrıca aktörlerin aralarında da nesneye dayalı programlamadan anımsayacağımız
genelleşme/özelleşme (generalization/specialization) ilişkisi bulunabilmektedir.
Örnekte kullanıcı adını verdiğimiz bir aktör vardır. Öğrenci ve öğretmen bu kullanıcının özel
halleridir. Danışman ise öğretmen aktörünün özel bir halidir.
Kullanım diyagramı incelendiğinde tüm kullanıcıların (öğretmen ya da öğrenci) sisteme giriş
senaryolarında aynı şekilde rol oynadıkları görülür.
Derse kayıtta ise öğrenci, sınıf listesini göster senaryolarında ise öğretmen aktörleri rol
oynamaktadır. Geç kayıt senaryolarında öğretmen aktörünün özel bir hali olan danışman
aktörü yer almaktadır.
24.11.23 4
24.11.23 5
 3.5. 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.
Örnek POS sistemine etkileşim diyagramı Şekil 3.4' te gösterilmiştir. Bu
örnekte aktör kasa görevlisidir. Kasa görevlisi ile sistem arasındaki mesaj
akışı (etkileşim) diyagramda gösterilmiştir.
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.

24.11.23 6
24.11.23 7
3.6. Kullanım Senaryolarının Yazılması

Kullanım senaryoları, yazılım siparişini veren firma ile görüşülerek

yazılır. Bu görüşmelerde sistemin nasıl çalışacağı açıkça ortaya
konmalıdır. Yazılımı doğrudan kullanacak olan kişilerle de görüşmeler
yapılmalıdır. Bu görüşmelerde aşağıdaki sorular sorularak senaryoların
yazılmasında gerekli olan bilgilere ulaşılabilir.
Aktörlerin belirlenmesi ve aktörlerden yararlanarak sistem davranışının
belirlenmesi için sorulabilecek sorular aşağıdaki animasyonda verilmiştir.

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ı?

24.11.23 8
24.11.23
9
3.7. Kullanım Senaryoları Yönteminin Yararları

İsteklerin doğru ve eksiksiz olarak belirlenebilmesi yazılımın kalitesi

açısından önemlidir. Kullanım senaryoları yöntemi bu noktada aşağıdaki
yararları sağlar:

24.11.23 10
 Bölüm 4
Bölüm Hedefi
Model oluşturmaktaki amaç, çözülmek istenen probleme ilişkin (gerçek) dünyanın;
doğru, özlü, anlaşılır ve sınanabilir bir modelinin oluşturulmasıdır.
Uygulama domenindeki (application domain) modelleme, problemin çözümlenmesi
(analysis), yani anlaşılması aşamasını oluşturur.
Amaç problemin çözülmesi değil anlaşılmasıdır.
"Ne?" sorusunun cevabı aranır. "Nasıl?" sorusunun cevabı tasarımın konusudur.
Bu bölümü bitirdiğinizde,
Uygulamayı oluşturan kavramsal sınıfların (gerçek dünya varlıklarının) nasıl
belirleneceğini,
Kavramsal sınıflar arasındaki bağlantıların (ilişkilerin) nasıl belirleneceğini,
Kavramsal sınıflar niteliklerinin (attribute) nasıl belirleneceğini,
İstekleri anlamakta kullanılan sözleşmelerin (contract) nasıl yazılacağını,
Sonuç olarak bir sistemin analizinin nasıl yapıldığını,
öğrenmiş olacaksınız.

24.11.23 11
4.1. 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.
İ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 olarak Şekil 4.1' de bu ders boyunca üzerinde çalışılacak olan POS (market satış) sisteminin
analiz modeli tamamlandığında çizilecek olan sınıf diyagramının bir kısmı gösterilmiştir.Şekil 4.1'
deki diyagramın nasıl oluşturulduğu ve kullanılan simgelerin anlamları ilerleyen bölümlerde
açıklanacaktır.

24.11.23 12
24.11.23 13
4.2. Kavramsal Sınıfların Belirlenmesi (Bulunması)

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.

24.11.23 14
4.2.1. Kavramsal Sınıfların Kategorileri

Deneyimlerden yararlanılarak uygulama domenindeki sınıfların hangi

kategorilerde yer aldığı belirlenmiş ve bir liste yapılmıştır.
Modellenecek olan uygulama incelenerek bu listedeki kategorilere
uyan unsurlar belirlenmeye çalışılır.
Bazı kategoriler ve örnek kavramsal sınıflar:

24.11.23 15
24.11.23 16
4.2.2. 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.
Bu yöntemin uygulanmasına örnek olarak ders notlarının 3.3. bölümünde
yazılan SG1 numaralı "Satış İşlemleri" senaryo grubu ele alınacaktır.
Yinelemeli (iterative) yazılım geliştirmede her yinelemede (iteration)
senaryoların sadece bir kısmı üzerinde çalışılıyor olabilir. Bu örnekte de sadece
senaryo grubunun doğal akış kısmı ele alınmış ve burada isim ve isim
tamlamaları işaretlenmiştir.
Her ismin bir defa işaretlenmesi yeterlidir.

24.11.23 17
24.11.23 18
4.2.2.1. Gereksiz Sınıfların Elenmesi

Senaryolardaki tüm isimler kavramsal sınıflara karşılık gelmez.

Gereksiz sınıfların elenmesi gerekir. Hangi sınıfların gereksiz olduğu
aşağıda sıralanmıştır:

24.11.23 19
4.2.3. Problem Domeni Modelini Oluşturmada Haritacı
(Mapmaker) Yöntemi

Gerçek dünyanın haritasını oluşturmada yaralanılan kavramlar

burada da kullanılabilir:

24.11.23 20
4.2.4. Örnek POS Sistemine Ait Kavramsal Sınıflar

Örnek probleme ilişkin kavramsal sınıflar Şekil 4.2' de gösterilmiştir.

Her sınıfın anlamını açıklayan bir sözlük hazırlanması yararlı olacaktır.

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.

24.11.23 21
4.2.5. Betimleme (Specification or description) 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 Şekil 4.3' te gösterildiği gibi başka
sınıflarda tutulması gerekir.

Ne zaman gerek duyulur?

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.
24.11.23 22
4.3. 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.

24.11.23 23
 4.3.1. Bağlantıların UML Diyagramlarında Gösterilmesi

Bağlantılara ilişkin UML notasyonu sekil 4.4' te gösterilmiştir:

Şekil 4.4: Bağlantılara ilişkin UML notasyonu

24.11.23 24
4.3.2. Ç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. Şekil 4.5' teki
örnekte bir malın tükenip depoda bulunmaması bizi ilgilendiriyorsa Depo
ucuna ait çoğullama sayısı 0..1olabilir. Aksi durumda bu
sayının 1 olması yazılım açısından daha uygundur.

24.11.23 25
 4.3.3. Bağlantıların Bulunmasına İlişkin Yöntemler

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

1.Yaygın Bağlantılar Listesi (Common Associations List)
2.Kullanım senaryolarındaki fiillerden yararlanmak.
Bu bölümde yaygın bağlantılar listesinden yararlanılacaktır.

24.11.23 26
4.3.3.1. Yaygın Bağlantılar Listesi (Common Associations
List)
Bu yöntemde, kavramsal sınıflar arasında aşağıdaki ilişkilerin varlığı
aranır:

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.
24.11.23 27
4.3.3.2. 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:

Ö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.
24.11.23 28
4.3.4. 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ı içeren örnek UML sınıf diyagramları Şekil 4.7' de gösterilmiştir.

•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şırlılığını azaltabilir.

24.11.23 29
4.3.4.1. Örnek POS Sisteminin Bağlantıları Da İçeren UML Sınıf Diyagramı
Derste ele alınan örnek POS sisteminin bağlantıları da içeren UML sınıf
diyagramı şekil 4.8' de gösterilmiştir.

24.11.23 30
4.4. 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.
Şekil 4.9'da gösterilen örnekte Terminal, Kasa Görevlisi tarafından kullanılan bir varlıktır ama
onun niteliği değildir.

24.11.23 31
4.4.1. 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.
Bu tip nitelikler şekil 4.10' da gösterildiği gibi iki farklı şekilde de ifade
edilebilir.

24.11.23 32
4.4.2. Birimleri Olan Niteliklerin Gösterilmesi
Birimleri olan büyüklükleri de basit veri tipleri ile göstermek doğru
olmaz. Örneğin şekil 4.11' de 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.

24.11.23 33
4.4.3. 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) olduğunu belirtir.
"/" simgesi ise bir niteliğin diğer niteliklerden türetilebilen (elde edilebilen)
(derived) bir nitelik olduğunu belirtir.
Şekil 4.12' de niteliklerin sınıf diyagramlarında nasıl yer alacağı gösterilmiştir.

24.11.23 34
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 POS sistemine ilişkin uygulama domeni modelinin bir
kısmı Şekil 4.13'te UML sınıf diyagramı şeklinde gösterilmiştir.

24.11.23 35
 4.5. Kullanım Senaryolarında Sözleşmeler (Contracts)

Birçok uygulamada kullanım senaryolarını (use-case) yazmak isteklerin

modellenmesi için yeterlidir. Bazı durumlarda karmaşık işlemlerin daha iyi
anlaşılabilmesi için sözleşmeleri yazmak yararlı olur.
Sözleşmeler, ön koşullar sağlandığında sistemdeki işlemler gerçekleştirilince
sistemin (uygulama domeni nesnelerinin) alacağı durumların (son koşullar) tarif
edilmesidir.
Senaryolarda, aktörler ile sistem arasındaki etkileşim belirtilir. Sözleşmelerde
ise sistem içi nesnelerdeki değişim de belirtilebilir.

Sözleşmelerde sözü edilen nesneler uygulama domeni (gerçek

dünya) nesneleridir.
Sözleşmeleri yazmaktaki amaç problemi çözmek değil anlamaktır.
Senaryoların yazılmasına benzer şekilde, sözleşmelerin de bölümleri ve
bir yazım biçimleri vardır.
Sözleşmelerin bölümleri:
24.11.23 36
 4.5.1. Örnek

Bu örnekte, şekil 4.14' te gösterilen senaryoda yer

alan urunGir işlemi için sözleşme yazılmıştır. Sözleşmenin
adı urunGir numarası ise SO2' dir.

24.11.23 37
24.11.23 38
Sözleşme (Contract) SO2: urunGir
İşlem: urunGir(urunkodu: UrunKodu, miktar: integer)
Referans: Senaryo Grubu SG1: Satış İşlemleri
Ön Koşul: Bir satış başlamış olmalı
Son Koşullar:
Bir SatışKAlemi nesnesi sk yaratıldı. (Nesne yaratma)
sk o anda geçerli olan Satış ile ilişkilendirildi. (Bağlantı oluşturma)
sk.miktar girişte verilen miktara eşitlendi. (Nitelik güncelleme)
sk, urunKodu kullanılarak uygun UrunTanımlayıcı ile ilişkilendirildi. (Bağlantı oluşturma)
Burada sözü edilen nesneler (örneğin sk), bağlantılar ve niteliklerin hepsi uygulama
domeni ile ilgilidir.
Sözleşmeler, uygulama modelinde bazı değişiklikler (eklemeler) yapılmasına neden olabilirler.
Aşağıdaki örnekte SatisBitir() işlemi için sözleşme yazılmıştır. Bu sistemde, biten satışların
silinmediği sadece "bitti" olarak işaretlendiği varsayılmıştır. Sözleşme yazılırken Satış
sınıfında bitti_mi adlı mantıksal (Boolean) bir niteliğin olduğu görülür ve bu nitelik analiz
modeline eklenir. Bu nitelik analiz yapılırken gözden kaçmış olabilir.
Örnek: endSale
Sözleşme (Contract) SO3: satisBitir
İşlem: satisBitir()
Referans: Senaryo Grubu SG1: Satış İşlemleri
Ön Koşul: Bir satış başlamıştır
Son Koşul: Satış.bitti_mi niteliğine doğru (true) değeri atandı (Nitelik güncelleme)
24.11.23 39
 Tüm arkadaşalarıma
katılımlarından dolayı teşekkür
ediyorum.

24.11.23 40