BLG4146 - Sistem Analizi ve Tasarımı Öğr. Grv. Aybike ŞİMŞEK
Tasarım Yöntemleri Yapısal Tasarım Veri akışına Yönelik Tasarım Veriye Yönelik Tasarım Nesneye Yönelik Tasarım 2
Veri Akışına Yönelik Tasarım Bilgi Bilgi Yazılım Sistemi Yazılım tasarımında bilgi akışı dikkate alınarak veri akış diyagramları kullanılır. Veri akışı çözümlemesi, yüksek uyumlu modüller oluşturabilmek için kullanılan klasik tasarım tekniğidir. Ana nokta: Veri akış diyagramı oluşturulduğu anda, yazılım tasarımcısı ürünle ilgili girdi ve çıktılarla ilgili açık ve net bir bilgiye sahip olur. 3
Veri Akışına Yönelik Tasarım Bu yöntem, yazılım belirtiminden şunları tanımlayan yazılım yapısına ulaşmayı sağlar: yazılımın oluşturulduğu modüller bu modüller arasındaki ilişkiler Programlama dilleri genellikle modüller için yapılar sağlarlar: Cobol: subprogram Fortran: subroutine Pascal: procedure, function C: function C++: class Java: class 4
Veri Akışına Yönelik Tasarım Her türlü yazılım veri akış diyagramı ile gösterilebilir. Özellikle sıradüzensel veri yapılarının bulunmadığı ve bilgilerin ardışık olarak işlendiği yazılımlar için daha kullanışlıdır. Kullanıcı etkileşimi çok azsa veya yoksa, sistemin çalışması sürekli veri akışına bağlıysa kullanılır. Karmaşık sayısal çözümleme yazılımları Kontrol sistemleri yazılımları Veritabanı sistemleri, nesneye yönelik arayüzlerin bulunduğu sistemlerde diğer yöntemlerin kullanılması daha uygun olur. 5
Akış Türleri Yazılım isterlerini veri akışına yönelik olarak aktarabilmek için bilgi akışının program yapılarına dönüştürülmesi gerekir. Bilgi akışının, sınırların, işleme şeklinin ve yapıların tanımlanması gereklidir. 6
Akış Türleri Büyük sistemlerde, hem dönüşüm hem de ara-işlem akışı bulunabilir. Dönüşüm (transform) akışı Her sisteme dış dünyadan bir giriş vardır Girişler sistem içinde işlenir ve dış dünyaya çıkış şeklinde gönderilir Giriş akışı sistemin dönüştürülür dönüşüm merkezinde işlenir ve çıkışa Her giriş bu merkezde ardışık sıra ile işlenir ve bir dönüşüm akışını oluşturur Ara-işlem (transaction) akışı Giriş şeklinde gelen bir veri akışı bir veri öğesine göre çeşitli akış yollarından birine yönlendirilerek bir başka veri akışını tetikleyebilir. Bu şekilde bir ara işlem akışı oluşur. Her akışta ara-işlem değerlendirilerek elde edilen değere göre bir hareket yolu seçilir. 7
Dönüşüm (Transform) Akışı 8
Dönüşüm (Transform) Akışı Yazılım İsterleri Belirtiminde (SRS) anlatılan sistem özellikleri ile Düzey0 VAD kullanılarak bilgi akışları, yapı ve arayüzler incelenir. VAD daha ayrıntılı hale getirilerek Düzey1 ve Düzey2 diyagramları hazırlanır. Düzey1 ve Düzey2 VADlar incelenip, dönüşüm akış özellikleri olanlar aranır. Girişten çıkışa doğru giden akışlar ele alınır, ara-işlem dönüşümü olup olmadığına bakılır. Bilginin yorumlanarak girişe dönüştürüldüğü yerler İşlenen verilerin çıkış bilgisi haline dönüştürüldüğü yerler Akış Sınırları Bunlar arasında kalan süreçler dönüşüm merkezi Önce giriş, dönüşüm ve çıkış akışları üzerinde bulunan süreçler modüllere dağıtılır, sonra da kalan süreçler en uygun modüllere bölüştürülür. Genel tasarım ilkeleri göz önüne alınarak program yapısı iyileştirilir. Bir kısım modüller birleştirilir ya da daha küçük parçalara bölünür, sonuçta iyileştirilmiş bir program yapısı elde edilir. 9
Dönüşüm (Transform) Akışı 10
Dönüşüm (Transform) Akışı UNIX/LINUX daki WC programındaki gibi dosya adını girdi olarak alıp, dosyadaki kelime sayısını döndüren programın tasarımını düşünelim. 11
Dönüşüm (Transform) Akışı 12
Dönüşüm (Transform) Akışı 13
Ara-işlem (transaction) akışı Giriş şeklinde gelen bir veri akışı, bir veri öğesine göre, çeşitli akış yollarından birine yönlendirilerek bir başka veri akışını tetikleyebilir. Her akışta ara-işlem değerlendirilerek elde edilen değere göre bir hareket yolu seçilir. 14
Ara-işlem (transaction) akışı VAD diyagramları gözden geçirilir ve gerekiyorsa düzeltme yapılır VAD üzerinde nerede dönüşüm, nerede ara-işlem akışı olduğu araştırılır Bir giriş ve birden fazla çıkış olan süreçler ara-işlem merkezi Her çıkış, yani her eylem yolu için akış özellikleri tanımlanır. Giriş ve çıkış yoları arasındaki sınırlar çizilir Ara-işlem akışı, dağıtıcı (dispatcher) bir program yapısına uydurulur. Girişe göre yapılacak bir dallanmada kullanılacak modüller tanımlanmış olur Genel program yapısı gözönünde bulundurularak program yapısı iyileştirilir. 15
Ara-işlem (transaction) akışı 16
Ara-işlem (transaction) akışı Bölünmemesi gereken işlemler. ATM kontrol eden yazılım Banka müşterisi, kartını ATM ye takar, şifresini girer ve aşağıdaki gibi bir takım işlemler gerçekleştirebilir Kredi kartı, yatırım ya da mevduat hesabına para yatırma Hesaptan para çekme Bakiye görüntüleme. 17
Ara-işlem (transaction) akışı 18
19
Tasarım Nitelikleri İsterler ile izlenebilirliği olmalıdır Geliştirilen birimin kodu ve testleri ile izlenebilirliği olmalıdır. Programlama dilinden olabildiğince bağımsız olmalıdır Öğrenmesi ve kullanımı kolay bir ürünü hedeflemelidir Tekrar kullanılabilir olmalıdır Kolay anlaşılmalıdır Gerektiğinde kolaylıkla değiştirilebilmelidir. 20
Yapışıklık (Kohezyon) nedir? Modül içerisindeki etkileşim derecesi Az mı çok mu? Çok olmalı Eğer çok olursa, modüller diğer modüllerin karmaşıklığıyla uğraşmaya gerek duymaksızın tasarlanabilir, kodlanabilir ve test edilebilirler. Modül içerisinde bir hata olursa diğer modüllere yayılması önlenmiş olur 21
Bağlaşım (coupling) nedir? Modüller arası etkileşim derecesi Az mı çok mu? Az olmalı Tavsiye edilen en fazla ikiden dörde kadar parametrenin kullanılması Karmaşıklığı azaltır 22
Yapışıklık ve bağlaşım 23
Anlaşılabilirlik Tasarımla ilgilenecek herkes onu kolaylıkla anlayabilmelidir. Yapışıklık ve bağlaşım: Bileşen başka bileşenlerden bahsetmeden de anlaşılabilir mi? İsimlendirme: Bileşenler için kullanılan isimlendirmeler anlamlı mı? Belgelendirme: Bileşenler gerçek dünya ve bileşenler arasında eşleştirme yapabilmeyi sağlayacak şekilde belgelendirilmişler mi? Karmaşıklık: Bileşeni gerçekleştirmek için uygulanacak algoritmalar ne kadar karmaşık? 24
Adapte olabilirlik Tasarımın ne kadar kolay değiştirilebileceğidir. Bağlaşım: Bileşenler düşük bağlaşımlı olmalı Anlaşılabilirlik: Belgelendirme anlaşılabilir hazırlanmış olmalı Adapte olabilir sistem, farklı düzeydeki tasarım modelleri arasında yüksek oranda takip edilebilirliğin olduğu sistemlerdir. 25
Nesneye Yönelik Tasarım Nesneye yönelik yaklaşım nesnelerin özellikleri ve ilgili oldukları süreçler ön planda 26
Hatırlatma:Nesneye yönelik temel kavramlar Kapsülleme(Encapsulation): Veri ve süreç paketlerinin bir arada paketlenmesi Gereksiz detayların gizlenmesi de bu özellik tarafından sağlanmaktadır. 27
Hatırlatma:Nesneye yönelik temel kavramlar Kalıtım(Inheritance): Daha genel nesne sınıflarından daha özel nesne sınıflarının özellik ve süreç edinmeleri Sınıftan sınıf üretimi 28
Hatırlatma:Nesneye yönelik temel kavramlar Çok şekillilik(polymorphism): Aynı isimle tanımlanan bir sürecin, hangi nesne tarafından harekete geçirildiği ile ilgili olarak kendiliğinden değişik davranışlara girebilmesi. Örn: Şekildeki nesnelerin türüne bakılmaksızın koşturulması 29
Nesneye yönelik çözümlemeden tasarıma geçilmesi 30
Nesne Yönelimli Yazılım Tasarımının Genel Şeması Tasarım aşamasında öncelikle senaryo ve sözleşmelerden sorumluluklar belirlenir. Ardından tasarım kalıpları (desenleri) ve prensipleri kullanılarak bu sorumluklar uygun sınıflara atanır. Tamamlanan tasarım UML diyagramları ile ifade edilir. Use-case Sequence 31
Nesne Yönelimli Yazılım Tasarımının Genel Şeması 32
Tasarım Kalıpları Tasarım aşamasında, yazılım sınıfları ve aralarındaki işbirliği (etkileşim) belirlenir. Burada amaç, senaryolarda belirlenmiş olan sorumlulukların (sistemden beklenenler) uygun sınıflara atanması (assignment of responsibilities) ve bu sınıfların tasarlanmasıdır. Nesnel tasarım (object design) gerçekleştirilirken sınıfların nasıl oluşturulacağı ve sorumlulukların nasıl atanacağı konusunda tasarım kalıplarından (design patterns) yararlanılır. 33
Sınıfların Sorumlulukları Nesnel Tasarımın (Object Design)genel ifadesi İsteklerin belirlenmesi ve uygulama alanı, ortamı modelinin oluşturulmasından sonra; Yazılım sınıflarına metotların eklenmesi (sorumlulukların atanması) İstekleri yerine getirmek üzere nesneler arası mesajların belirlenmesi Nesnel tasarımın temeli nesnelere sorumlulukların atanmasıdır. Nesnelerin sorumlulukları 2 gruba ayrılır: Bilinmesi gerekenler Yapılması gerekenler 34
Sınıfların Sorumlulukları 35
Sınıfların Sorumlulukları Sorumlulukları yerine getirmek için metotlar oluşturulur. Bir sorumluluğu yerine getirmek için bir metot başka nesnelerdeki metotlarla işbirliği yapabilir. Bir sistemdeki sorumluluklar o sistem için yazılmış olan senaryolardan (use-case) ve sözleşmelerden (contract) elde edilir. Daha sonra bu sorumluluklar tasarım prensipleri ve kalıpları kullanılarak uygun sınıflara atanır. 36
Tasarım Kalıpları (Design Patterns) Hangi yazılım sınıfına hangi sorumlulukların atanacağını ve hangi sınıflarla işbirliği yapılacağını belirlemek için tasarım prensiplerinden ve kalıplardan yararlanmak gerekir. Tasarım kalıplarının varlığı ilk olarak bir mimar olan Christopher Alexander tarafından ortaya konulmuştur. Bu süreçte sorulan sorular şunlardır: 37
Tasarım Kalıpları (Design Patterns) Christopher Alexander yaptığı araştırmalar sonunda benzer problemleri çözmek için oluşturulan ve beğenilen (kaliteli) mimari yapılarda ortak özellikler (benzerlikler) olduğunu belirlemiştir. Bu benzerliklere kalıplar (patterns) adını vermiştir. Her kalıp gerçek dünyada defalarca karşılaşılan bir problemi ve o problemin çözümünde izlenmesi gereken temel yolu tarif etmektedir. Türkçesi: "Aklın yolu birdir." 38
Tasarım Kalıpları (Design Patterns) Bir problemle karşılaşan tasarımcı eğer daha önce benzer problemle karşılaşan tasarımcının uyguladığı başarılı çözümü biliyorsa (kalıp) herşeyi yeniden keşfetmek yerine aynı çözümü tekrar uygulayabilir. Mimarlıkta olduğu gibi yazılım geliştirmede de benzer problemlerle defalarca karşılaşılmaktadır. Yazılımcılar deneyimleri sonucunda birçok problemin çözümünde uygulanabilecek prensipler ve deneyimler (kalıplar) oluşturmuşlardır. 39
Tasarım Kalıpları (Design Patterns) Bu konudaki ilk önemli yayın dört yazar tarafından hazırlanan bir kitap olmuştur: GammaE., HelmR., JohnsonR., VlissidesJ., Design Patterns, ReadingMA, Addison-Wesley,1995. Bu yazarlara dörtlü çete (Gang of Four) adı takılmış ve ortaya koydukları kalıplar GoFkalıpları olarak adlandırılmıştır. Toplam 23 adet GoF vardır 40
GRASP: Genel Sorumluluk Atama Kalıpları GRASP (General Responsibility Assignment Software Patterns) nesnelere sorumluluk atamada yol gösteren temel kalıpların genel adıdır. Bu kalıplar daha çok eğitim amaçlıdır. Öğrencilere nesneye dayalı tasarımı öğretmek ve kalıpların kullanımını göstermek için kullanılırlar. Profesyonel dünyada yazılım geliştirmede büyük çoğunlukla GoF kalıpları kullanılmaktadır. Kalıplar 3 bölümden oluşur: İsim Problem Çözüm Bu üç temel bölümün dışında kalıplarda açıklayıcı ve yardımcı ek bölümlerde bulunabilir. 41
GRASP: Genel Sorumluluk Atama Kalıpları Eğitim amaçlı kullanılan GRASP çeşitleri: Bilginin Uzmanı (Information Expert or Expert) Yaratıcı (Creator) Az Bağımlılık (Low Coupling) Denetçi (Controller) İyi Uyum (High Cohesion) Çok Şekillilik (Polymorphism) Yapay Sınıf (Pure Fabrication) Dolaylılık ya da Arabirim (Indirection) Değişimlerden Korunma (Protected Variation) 42
1.Bilginin Uzmanı (Information Expert or Expert) Sorumlulukları atamakta kullanılan en temel prensiptir. Kalıbın ilgilendiği problem ve çözümü şu şekildedir: Problem: Nesnelere sorumlulukları atamanın temel prensibi nedir? Çözüm: Bir sorumluluğu bilginin uzmanına, yani onu yerine getirecek veriye (bilgiye) sahip olan sınıfa atayın. 43
1.Bilginin Uzmanı (Information Expert or Expert) Örnek: Market sisteminde satışın toplam bedelinin bilinmesine gerek vardır. Satışın toplam bedelinin belirlenmesinden kim sorumludur? Uzman kalıbına göre bu bilgiye sahip olan sınıf aranacak. Arama önce yazılım sınıfları arasında yapılır. Eğer henüz böyle bir yazılım sınıfı oluşturulmamışsa analiz aşamasında oluşturulan uygulama alanındaki kavramsal sınıflar incelenir. Bunlardan uygun olan kavramsal sınıf, tasarım modeline yazılım sınıfı olarak getirilir. 44
1.Bilginin Uzmanı (Information Expert or Expert) Örnek: Burada Satis kavramsal sınıfı bu sorumluluğu almak için uygun görünmektedir, çünkü toplam tutarı belirleyebilecek bilgilere sahiptir (uzmandır). Satış, satış kalemlerini içerir. Satış kalemlerinde miktar bilgisi vardır. Satış kalemleri ürün tanımına bağlıdır. Ürün tanımlarında da her ürünün fiyatı vardır. 45
1.Bilginin Uzmanı (Information Expert or Expert) Örnek (dvm): Bu kavramsal sınıftan aynı isimde bir yazılım sınıfı oluşturulabilir. Şekil de uzman kalıbına göre yeni oluşturulan ve toplam tutarı verme sorumluluğu kendisine atanan yazılım sınıfı Satis'in iletişim ve sınıf diyagramları gösterilmiştir. Satis'a ait tutariver metodu ona atanan sorumluluğu yerine getirmektedir. 46
1.Bilginin Uzmanı (Information Expert or Expert) Örnek (dvm): Satis sınıfı tek başına toplam bedeli belirleyemez. Satış kalemlerinin bedellerine gerek vardır. Bunun için her satış kaleminin bedeli SatisKalemi sınıfından alınacaktır. SatisKalemi bir kalem bedelini belirleyebilmek için miktar (adet) bilgisine sahiptir. Bir ürünün birim fiyatını UrunTanimi sınıfından alacaktır. Toplam tutarı hesaplamak için sınıflar arasında gerçekleşen iş birliği şekilde gösterilmektedir: 47
1.Bilginin Uzmanı (Information Expert or Expert) Örnek (dvm): Toplam tutarı hesaplamak için oluşturulan yeni yazılım sınıfları aşağıdaki şekilde gösterilmektedir: 48
2. Yaratıcı (Creator) En sık karşılaşılan sorumluluklardan biri de nesne yaratmaktır. Bir nesnenin yaratılma sorumluluğunun kime (hangi sınıfa) verileceği konusunda yaratıcı kalıbı yol gösterir. Problem: Bir sınıftan nesne yaratma sorumluluğu kime aittir? Çözüm: Aşağıdaki koşullardan biri geçerli ise B sınıfına A sınıfından nesne yaratma sorumluluğunu atayın. B, A nesnelerini içeriyorsa. B, A nesnelerinin kaydını tutuyorsa. B, A nesnelerini yoğun olarak kullanıyorsa. A nesnelerinin yaratılması aşamasında kullanılacak olan başlangıç verilerine B sahipse (B, A'nın yaratılması açısından bilgi uzmanıdır.) Bu koşulları sağlayan birden fazla sınıf varsa öncelik yaratılacak olan nesneyi içeren sınıfa verilmelidir. 49
2.Yaratıcı (Creator) Örnek: Satış kalemlerini kim yaratacak? Uygulama modeli incelendiğinde bir satışın birçok satış kalemi içerdiği görülür. Buna göre satış kalemlerini yaratmak satışın sorumluluğu olacaktır. 50
2.Yaratıcı (Creator) 51
3. Az Bağımlılık (Low Coupling) Bir sınıfın bağımlılığı şunlarla ilgilidir: Kendi işleri için başka sınıfları ne kadar kullandığı Başka sınıflar hakkında ne kadar bilgi içerdiği 52
3. Az Bağımlılık (Low Coupling) Nesneye dayalı programlarda SınıfX'in SınıfY'ye bağımlılığı aşağıdaki durumlarda ortaya çıkar: 53
3. Az Bağımlılık (Low Coupling) Az bağımlılık kalıbı aşağıdaki şekilde ifade edilir: Problem: Diğer sınıfların değişimlerinden etkilenmeme ve tekrar kullanılabilirlik nasıl sağlanır? Çözüm: Sorumlulukları, sınıflar arası bağımlılık az olacak şekilde atayın. 54
3. Az Bağımlılık (Low Coupling) Örnek Market sisteminde bir ödeme nesnesinin yaratılıp satış nesnesi ile ilişkilendirilmesi gerekiyor. Gerçek dünyada ödeme Market terminaline yapıldığından gerekli bilgilere sahip olan :Terminal nesnesidir. Yaratıcı kalıbına göre :Terminal nesnesi :Odeme nesnesini yaratacaktır. Bu tasarım aşağıdaki şekilde gösterilmiştir. 55
3. Az Bağımlılık (Low Coupling) Örnek Tasarım bu şekilde gösterildiği gibi yapıldığında :Terminal nesnesine ödeme miktarı (nakit) gelmektedir. Ödeme ile ilgili bilgilere :Terminal sahip olduğundan adresi odm olan bir Odeme nesnesi yaratmaktadır. 56
3. Az Bağımlılık (Low Coupling) Örnek Ödeme bilgileri daha sonra Satış tarafından kullanılacağından odm adresi bir mesajla (ekleodeme(odm)) :Satis nesnesine verilmektedir. Bu durumda Terminal sınıfı hem Odeme sınıfına hem de Satis sınıfına bağımlıdır çünkü bu sınıflara mesaj göndermekte onları kullanmakta ve yaratmaktadır. Dolayısıyla onlar hakkında bilgi sahibi olmak zorundadır. 57
3. Az Bağımlılık (Low Coupling) Örnek Aşağıdaki şekilde gösterilen tasarımda ise Terminal sınıfı kendisine gelen OdemeYap mesajını Satis sınıfına havale (delagate) etmektedir. Daha sonra Odeme nesnelerini Satis kullanacağı için bu nesneleri Satis yaratmaktadır. Bu tasarımda Terminal sınıfı Odeme sınıfına bağımlı değildir, çünkü bu sınıfla hiçbir iletişimi yoktur. 58
4.Denetçi (Controller) Sistem olayları (system event), dış aktörler tarafından üretilen ve sistem işlemleri (system operations) ile ilişkili olaylardır. Örneğin Market sisteminde kasa görevlisi "SatışBitti«tuşuna bastığında bir sistem olayı yaratmış olur. Problem: Sistem olaylarını arayüz katmanından alıp ilgili nesnelere yönlendirmekle kim sorumludur? Çözüm: Sistem olaylarını algılama ve değerlendirme sorumluluğunu alacak sınıfı aşağıdaki iki seçenekten birini kullanarak oluşturun: 1. Tüm sistemi, cihazı veya altsistemi temsil eden bir sınıf (facade controller). Cephe denetçi 2. Bir kullanım senaryosunu temsil eden sınıf (use-case or session controller). Senaryo veya oturum denetçisi 59
4.Denetçi (Controller) Denetçi nesneleri sistem olaylarını algıladıktan ve bazı kontrol işlerini yaptıktan sonra çoğunlukla bu olayları, ilgili işlemleri yapacak olan nesnelere yönlendirirler. Şekil de gösterilen denetçi nesne, arayüzden gelen mesajları alacak, gerekli kontrolleri yapacak (örneğin sıraları doğru mu?) ve o mesajı asıl işi yapacak olan ilgili nesneye gönderecektir. 60
Denetçilerin Tasarlanması Denetçiler iki farklı şekilde tasarlanabilir: 1. Cephe denetçi (Facade Controller) Tüm sistem olaylarını algılamak tek bir denetçinin sorumluluğunda olur. 2. Oturum denetçisi (Session Controller) Her oturum (senaryo) için ayrı bir denetçi görevlendirilir. 61
Cephe denetçi (Facade Controller) Tüm sistem olaylarını algılamak tek bir denetçinin sorumluluğunda olur. Bu örnekte Terminal sınıfı tüm sistemin denetçisidir. 62
Oturum denetçisi (Session Controller) Her oturum (senaryo) için ayrı bir denetçi görevlendirilir. 63
5. İyi Uyum (High Cohesion) 64
5. İyi Uyum (High Cohesion) 65
5. İyi Uyum (High Cohesion) 66
5. İyi Uyum (High Cohesion) 67
Tasarımda İletişim Diyagramlarının Kullanımı İletişim (communication) diyagramları kullanılması durumunda şekil de gösterildiği gibi her sistem olayı (giriş) için ayrı bir diyagram çizmek gerekir. 68
Tasarımda Ardışıl Diyagramların Kullanımı Ardışıl (sequence) diyagramlarda ise tüm sistem olayları (giriş) aynı diyagram üzerinde gösterilebilir. 69
Tasarımda Ardışıl Diyagramlarının Her Giriş İçin Ayrı Çizilmesi Şekillerin karışık olmaması için Şekil de gösterildiği gibi ardışıl (sequence) diyagramlarda sistem olaylarına göre ayrı ayrı çizilebilir. 70
Tasarım Örneği: Satışın Başlatılması 71
Tasarım Örneği: Satışın Başlatılması 72
Tasarım Örneği: Satışın Başlatılması 73
Tasarım Örneği: Satışın Başlatılması 74
SORULARINIZ 75