NESNE YÖNELİMLİ PROGRAMLAMA HAFTA # 8

NESNE YÖNELİMLİ PROGRAMLAMA HAFTA # 8

Modelleme 2 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.

Prosedürel Tasarım 4 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.

Nesne-yönelimli Tasarım 5 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.

Sınıfların Belirlenmesi 6 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.

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.

UP Temel Özellikler 11

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

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.

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

Ö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

Ö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:

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.

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.

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.

Niteliklerin Özelliklerinin Gösterilmesi

İçerik UML Yapı Diyagramları Eylem Diyagramları Etkileşim Diyagramları

UML

Diyagramlar UML görsel olarak modelleme için birçok diyagrama sahiptir. Yapı Diyagramları Eylem Diyagramları Etkileşim Diyagramları

Yapı Diyagramları UML' de altı tür yapı diyagramı vardır: Sınıf (Class) Diyagramları Nesne (Object) Diyagramları Paket (Package) Diyagramları Bileşen (Component ) Diyagramları Birleşik Yapı (Composite Structure) Diyagramları Dağıtım (Deployment) Diyagramları

Sınıf Diyagramı

Nesne Diyagramları

Paket Diyagramları

Bileşen (Component) Diyagramları

Bileşen (Component) Diyagramları

Birleşik Yapı (Composite Structure) Diyagramları Birleşik yapıların iki ayrı türü vardır: 1. Toplama, bir araya getirme (Aggregation) 2. Meydana gelme (Composition)

Toplama (Aggregation) 1. Toplama, bir araya getirme (Aggregation): İçerilen nesneler (alt parçalar) kendi başlarına da kullanılırlar. Sadece o nesneye ait parçalar değillerdir. Örneğin havaalanında uçaklar vardır.

Meydana gelme (Composition) 2. Meydana gelme (Composition): Alt parçalar o nesneyi meydana getirmek için oluşturulmuşlardır; kendi başlarına kullanılmazlar. Örneğin otomobilin motoru vardır.

Dağıtım (Deployment) Diyagramları

Eylem Diyagramları UML' de üç tür eylem diyagramı vardır: Kullanım Durumu (Use-Case) Diyagramları Durum (State) Diyagramları Aktivite (Activity) Diyagramları

Kullanım Durumu Diyagramları

Durum Diyagramları

Durum Diyagramları

Aktivite Diyagramları

Aktivite (Activity) Diyagramları

Aktivite (Activity) Diyagramları

Etkileşim Diyagramları UML' de iki tür etkileşim diyagramı vardır: İletişim Diyagramları (Communication Diagrams) Ardışıl Diyagramlar (Sequence Diagrams)

İletişim Diyagramları

Ardışıl Diyagramlar

İletişim Diyagramları Terminal adlı sınıftan yaratılmış bir nesnenin odemeyap(verilennakit) adlı metodu canlandırdığında bu metodun içinde Satis adlı sınıftan yaratılan bir nesneye odemeyap(verilennakit) adlı başka bir mesaj gönderilir. :Satis nesnesi bu metodun içinde Odeme adlı sınıftan bir nesne yaratır.

Mesaj Sıra Numaraları Mesajlar gönderildikleri sıraya göre numaralanırlar. İlk mesaja numara verilmez. Bir mesajın neden olduğu diğer mesajlara da sebep mesajın numarasına bağlı alt numaralar verilir. Aşağıdaki şekilde, ClassA' nın bir nesnesi ClassB' nin bir nesnesine msg2 mesajını yolladığında ClassB' nin nesnesi de ClassC' nin nesnesine msg3 mesajını gönderecektir. msg3 sonlandığında tekrar msg2' ye dönülecektir.

Kendine Mesaj Nesneler kendilerine de mesaj gönderebilirler, yani kendi metotlarını çağırabilirler. Şekildeki örnekte, :Terminal nesnesi, msg1 metodunun içinde kendi sil metodunu çağırmaktadır.

Nesne Yaratma Bir mesaj nesne yaratılmasını sağlamak için gönderiliyorsa normal olarak bu mesaja create adı verilir ve bir kurucu fonksiyon (constructor) çağrısı olarak yorumlanır. Eğer başka bir isim verilirse <<create>> tanımlayıcısı kullanılır. Aşağıdaki şekilde her iki durum da gösterilmiştir. Bu örnekte, :Terminal nesnesi :Satis nesnesini yaratmaktadır.

Koşullu Mesajlar Bu tür mesajlar sadece belli bir koşul gerçekleştiğinde gönderilebilirler. Eğer köşeli parantez içinde verilen koşul gerçekleşmemişse o mesaj gönderilmez, sonraki mesaja geçilir. Şekil de verilen örnekte A sınıfından yaratılan nesnenin mesaj1 metodunun içinde renk değeri sınanmaktadır. Eğer renk = mavi koşulu doğru ise :A nesnesi, :B nesnesine hesapla() mesajını gönderecektir. Koşul doğru değilse bir sonraki mesajla (örneğin 2 numaralı) devam edilecektir. Bu durum programlamadaki if-then yapısına karşı düşmektedir.

Karşılıklı Dışlamalı Mesajlar Nesneler arası etkileşim, belli bir koşula bağlı olarak farklı yollar izleyebilir. Şekil de verilen örnekte "test" koşuluna bağlı olarak a ya da b yollarından biri izlenecektir. Diyagramda gösterilen sistem SınıfA' dan yaratılan nesneye msg1() mesajının gelmesi ile çalışmaya başlar. Bu metodun içinde test koşuluna bakılır. Eğer test=true ise 1a numaralı msg2 SınıfB'den yaratılan nesneye gönderilir ve msg3() ile devam edilir. Eğer test=true değil ise 1b numaralı msg4 SınıfD' den yaratılan nesneye gönderilir. Koşullara bağlı mesajlar gönderildikten sonra SınıfA' dan yaratılan nesne SınıfE' den yaratılan nesneye koşulsuz olarak 2 numaralı msg6 mesajını gönderir.

Döngüler (İterasyonlar) UML iletişim diyagramlarında tekrarlamalar (döngüler) "*" sembolü ile gösterilir. Şekil de verilen örnekte Simulator sınıfından yaratılan nesne, i = 1' den N' e kadar Random sınıfından yaratılan nesneye nextint() mesajını defalarca gönderecektir. Bu metot çağrısında geri gönderilen değer num adlı bir değişkende tutulmaktadır. Eğer tekrarın kaç defa yapılacağı tasarım aşamasında belli değilse, kodlama aşamasına bırakılmışsa ya da problemin yapısından dolayı açıkça belli ise döngü koşulu yazılmadan sadece "*" simgesi de kullanılabilir.

Ardışıl (Sequence) Diyagramlar (Örnek) Market sisteminin ardışıl diyagramı aşağıdaki şekil de gösterilmiştir. Bu diyagramda da Terminal, Satis ve Odeme, sistem tasarlanırken oluşturulacak sınıfların adıdır. Bu nedenle Türkçe karakterler kullanılmamıştır.

Geri Dönüşler Mesajlardan geri dönüşleri göstermek çoğunlukla gerekli değildir. Gerekli olduğu durumlarda geri dönüşler kesik çizgi ile gösterilir. Çağırılan metodun geri döndürdüğü değer istenirse mesajın başına yazılır istenirse geri dönüş çizgisinin üstüne yazılır. Şekil de verilen örnekte her iki yöntem de gösterilmiştir. Örnekte, msg2() mesajı geriye a değerini döndürnketedir. Benzer şekilde msg3() çağrısı da geriye paraustu değerini döndürmektedir. msg4() ve msg5() çağrıları ise geriye değer döndürmemektedir.

Kendine Mesaj Şekil deki örnekte :Terminal nesnesi, msg1 metodunun içinde kendi sil metodunu çağırmaktadır.

Nesne Yok Etme Şekil deki örnekte :Satis nesnesi, önce :Odeme nesnesini yaratmakta daha sonra da yok etmektedir. Bu işlemler C++' da new ve delete operatörleri ile yapılır.

Koşullu Mesajlar Bu tür mesajlar sadece belli bir koşul gerçekleştiğinde gönderilebilirler. Eğer köşeli parantez içinde verilen koşul gerçekleşmemişse o mesaj gönderilmez, sonraki mesaja geçilir. Şekil de verilen örnekte A sınıfından yaratılan nesnenin msg1 metodunun içinde önce :B nesnesine msgx() mesajını gönderilmektedir. Ardından msg1 metodunda renk değeri sınanmaktadır. Eğer renk = mavi koşulu doğru ise :A nesnesi, :B nesnesine hesapla() mesajını gönderecektir. Daha sonra (koşul doğru olsa da olmasa da) bir sonraki mesajla (msgy() ) devam edilecektir.

Karşılıklı Dışlamalı Mesajlar (UML 1.X) Nesneler arası etkileşim, belli bir koşula bağlı olarak farklı yollar izleyebilir. Şekil de verilen örnekte "X>10" koşuluna bağlı olarak :B ya da :C nesnelerine hesapla mesajı gönderilir. Bu diyagram UML' in bir önceki sürümünde (1.X) kullanılan gösterilime göre çizilmiştir. Bu gösterilimde nesnelerin isimlerinin altı çizilmektedir.

Karşılıklı Dışlamalı Mesajların Yeni Biçimi (UML 2.x) UML 2.0' da karşılıklı dışlamalı durumları göstermek için "alt" anahtar sözcüğü kullanılır. Bu sözcüğün yanına koşullardan biri yazılır. Koşul gerçekleşmediği durumlarda gönderilecek mesajlar ise kalın bir kesik çizgiden sonra sıralanır. Bu grubun başına "else" anahtar sözcüğü yazılır. Şekil de UML 2.0' da karşılıklı dışlamalı mesajların ardışıl diyagramlarda nasıl çizildiği gösterilmiştir.

İterasyonlar (Döngüler) Şekil de UML' in eski sürümü 1.5' te tek mesajlı bir döngü yapısı gösterilmiştir. Bu örnekte Simulator sınıfından yaratılan nesne, i = 1' den N' e kadar Random sınıfından yaratılan nesneye nextint() mesajını defalarca gönderecektir.

İterasyonlar (Döngüler) Önceki örnekle aynı sistem UML' in 2.0 sürümü ile gösterilmiştir. UML in yeni sürümünde döngüler "loop" anahtar sözcüğü ile belirtilmektedir.

Diyagramlar Arası Etkileşim Altprogram çağırmak gibidir. Çok tekrarlanan işlemler için kullanılır. Başka diyagramdan alınacak olan kısım ana diyagramın içinde "ref" bloğu ile belirtilir. Bu bloğun içine aynı isimdeki ardışıl diyagramın yerleşeceği anlaşılır.

Genel Kurallar UML bir programlama (ya da yazılım geliştirme) dili olmaktan ziyade iş sistemlerinin nasıl modellenebileceğini belirleyen ve açıklayan yöntemlerin bir araya toplanmış halidir. Daha çok yazılım geliştiriciler tarafından kullanılıyor olsa da UML ile yapılan modellemeler sadece yazılım projelerinde kullanılmak zorunda değildir. Örneğin bir iş sistemin yapısını sade ve anlaşılır şekilde ortaya çıkarmak için Paket Diyagramı ("Package Diagram") kullanılabilir. Altın kural: Diyagramdaki elemanlar ve elemanları açıklayıcı yazılar ne kadar az olursa, diyagram o kadar açıklayıcı olur. Detayların tümünü bir diyagramda göstermeye çalışırsanız hem kendiniz hem de yazılımı kullanacak olanlar temel bakış açısını yitirebilirler.

Kaynaklar Buzluca, F. (2010) Yazılım Modelleme ve Tasarımı ders notları (http://www.buzluca.info/dersler.html) Kalıpsiz, O., Buharalı, A., Biricik, G. (2005). Bilgisayar Bilimlerinde Sistem Analizi ve Tasarımı Nesneye Yönelik Modelleme. İstanbul: Papatya Yayıncılık Sarıdoğan, E. (2004) Yazılım Mühendisliği, İstanbul: Papatya Yayıncılık