Unified Modeling Language

Konular MODELLEME Prosedürel Tasarım Nesne-yönelimli Tasarım Sınıfların Belirlenmesi Tümleştirilmiş Yazılım Geliştirme Süreci Kullanım Senaryolarının (Use-Cases) Tanımı

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 Yanlışlıkları ö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. 3

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

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

Senaryo 1 - a 20

Senaryo 1 - b 21

Senaryo 1 - c 22

Senaryo 1 - d 23

Senaryo 1 - e 24

Senaryo 2 - a 25

Senaryo 2 - b 26

Senaryo 2 - c 27

Senaryo 2 - d 28

Kullanım senaryoları 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/ 29

Aktör 30

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

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

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

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

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

Ö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. 39

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

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

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

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 43

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

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

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

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

İçerme vs. Genişletme 48

Kullanım Durumu Diyagramları (Use Case Diagram) 49

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

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

Market sistemi etkileşim diyagramı 52

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

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

İ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. 55

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

Market sistemi sınıf diyagramı 57

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: Kavramsal sınıfların kategori listesinden yararlanma Kullanım senaryolarındaki isimlerden (isim tamlamalarından) yararlanmak İki yöntem birlikte de kullanılabilir. 58

KAYNAKÇA Y.Doç.Dr.Feza BUZLUCA ders notları http://www.buzluca.info/dersler.html