TASARIMIN BELGELENDİRİLMESİ Bir nesneye yönelimli programın tasarım sürecinin belgelendirilmesinde yer alan önemli belgeler: Ayrıntılı UML sınıf şemaları: Vazgeçilmez. Tasarımın ihtiyaçlarına göre alttaki diğer belgelerin çeşitli bileşimleri de kullanılabilir: Sözleşmeler UML Etkileşim şemaları (Interaction diagrams) – Sıralama şemaları (Sequence diagrams) – İşbirliği şemaları (Collaboration diagrams) UML Etkinlik şemaları (Activity diagrams) UML Durum diyagramları (State diagrams)

Tasarım Kalıpları Yazılım sınıflarının belirlenmesinde ve onlara uygun sorumlulukların atanmasında tasarım kalıpları yaygın olarak kullanılmaktadır. Nesnel tasarımda sınıfları ve sorumlulukları belirlemeden önce tasarım kalıplarının incelenmesi faydalıdır. Sıklıkla karşılaşılan, tanımlanabilir bir probleme sistematik bir çözüm getiren prensiplere, tasarım kalıpları adı verilir. Tasarım kalıplarına problemine getirdiği çözümü belirten, kolay hatırlanan ve iletişimi kolaylaştıran isimler verilir. E. Gamma, R. Helm, R. Johnson ve J.Vlissides tarafından ortaya konulan kalıplar literatürde GoF kalıpları (Gang of Four) olarak bilinir. Toplam 23 adet olan GoF tasarım kalıpları yerine, genel olarak nesnelere sorumluluklarını atarken baz alınan genel sorumluluk atama prensiplerinden bahsedilecektir.

Yaratıcı (Creator) Bir sınıftan nesne yaratma sorumluluğunun kime verileceğini belirleyen kalıptır. Nesneye yönelik sistemlerde nesne yaratımı sıklıkla yapılan işlemlerden biridir. Yaratıcı kalıbına uygun davranıldığında tasarım az bağımlı, daha anlaşılır ve yeniden kullanılabilir olur. Aşağıda verilen koşullar geçerli olduğunda B sınıfına A sınıfından nesne yaratma sorumluluğu verilir: B, A nesnelerini içeriyorsa (kümeleme ilişkisi dahil) B, A nesnelerinin kaydını tutuyorsa B, A nesnelerini sıkı bir biçimde kullanıyorsa A’nın yaratılması için gerekli verilere B sahipse (B, A’nın yaratılmasında bilginin uzmanıysa) Kahve sitesinde, Sipariş Kalemi nesnesini kimin yaratacağı örnek olarak verilebilir. Uygulama modeli incelenirse bir Siparişin birçok Sipariş Kalemi içerdiği görülür. Bu yüzden sipariş kalemlerini yaratma sorumluluğu siparişindir.

Bilginin Uzmanı (Expert) Nesnelere sorumlulukları atamanın temel prensibidir. Bir sorumluluğun o bilginin uzmanına, onu yerine getirecek veriye sahip olan sınıfa atanmasını tanımlar Bir sorumluluğun atanmasında, öncelikle uzman kalıbına uygun olarak bu bilgiye sahip olan yazılım sınıfı aranır. Henüz böyle bir sınıf yoksa kavramsal sınıflar incelenir ve uygun sınıf tasarım modeline alınır. Kahve sitesinde bir siparişin toplam bedelinin bilinmesi sorumluluğunu almak için en uygun sınıf, Sipariş sınıfıdır. Ancak Sipariş tek başına bu bilgiye sahip değildir. Sipariş kalemlerinin toplam bedellerini bilme sorumlulukları kendilerindedir. Bir sipariş kaleminde birden fazla kahve yer alabilir. Bu durumda Sipariş Kalemi, kendi bedelini hesaplayabilmek için Kahve nesneleri ile işbirliği yapmalıdır.

Az Bağımlılık (Low Coupling) Diğer sınıflarda olabilecek değişimlerden etkilenmemeyi ve tekrar kullanılabilirliği tanımlayan tasarım kalıbıdır. Bağımlılık, bir birimin diğerlerine ne kadar bağlı olduğu, haklarında ne kadar bilgi sahibi olduğu ve işleri yerine getirebilmek için ne kadar diğer birimlere bağlı olduğunu gösteren bir ölçüttür. Fazla bağımlılık, aşağıdaki sebeplerden ötürü tercih edilmez. Bir sınıftaki değişim bağımlı diğer sınıfları da etkiler. Sınıfları birbirlerinden ayrı olarak (izole) anlamak zordur. Bağımlılıktan ötürü sınıfı yeniden kullanmak zordur. Kahve sitesi incelendiğinde, hem Sipariş hem de Ödemenin Müşteri ile ilişkili olduğu görülür. Gerçek dünyada da durum böyledir. Yaratıcı kalıbına göre Ödemeyi Müşterinin yaratması gerekir. Ancak bu durumda Müşteri, Ödeme hakkında bilgiye sahip olmalıdır. Oysa bu sorumluluk Sipariş sınıfına atanırsa, bağımlılık azaltılmış olur. Bir çözümün uygulanması diğer bir kalıba tam olarak uygun olmayabilir. Tasarım kalıpları birlikte kullanılarak en uygun tasarım çözümü oluşturulmalıdır.

Denetçi (Controller) Kullanıcı arabiriminin arkasında durarak sistem olaylarını alma ve kontrol etme sorumluluğunu alacak bir sınıfa ihtiyaç duyulmaktadır. her bir kullanım senaryosunu temsil eden bir sınıf denetçi olarak atanır. Uygulamalarda yer alan “window”, “applet”, “frame” gibi yapılar denetçi sınıflar değildir. Bunlar sadece sistem olaylarını ilgili denetçiye aktarırlar. Denetçi nesneleri sistem olaylarını algıladıktan ve kontrol işlerini yaptıktan sonra bu olayları ilgili işlemleri yapacak olan nesnelere yönlendirirler.

İyi Uyum (High Cohesion) Nesneye yönelik bir programda nesneler, kendilerine atanan sorumlulukları yerine getirmekle yükümlüdür. Bir sınıfa atanan sorumlulukların birbiri ile ilgili olması ve belirli bir konuya yoğunlaşması beklenir. Eğer bir sınıf çok fazla iş yapıyorsa ve sorumlulukları birbirinden farklı ise, sınıfta uyum kötüdür. Bu durumda sınıfın anlaşılırlığı azalır, tekrar kullanım zorlaşır. Birlikte çalıştığı çok fazla sınıf olacağı için, sınıf değişimlerden daha çok etkilenir. Karmaşıklığın idare edilebilmesi için sorumluluklar, sınıf içinde iyi uyum olacak şekilde atanmalıdır. Kahve sitesi örneğinde az bağımlılık kalıbında incelenen durum iyi uyum kalıbı için de geçerlidir. Gerçek hayatta Ödemeyi Müşteri gerçekleştirir. Ancak uygulama açısından bakıldığında Ödeme hakkında bilginin uzmanı Sipariş sınıfıdır. Müşterinin Ödeme ile ilgili sorumlulukları taşıması yerine, zaten bilgiye sahip olan Sipariş sınıfını bu sorumluluğu taşıması iyi uyum kalıbına uygun olacaktır.

Çok şekillilik (Polymorphism) Birbiriyle ilgili ancak tiplere göre değişiklik gösteren davranışları tasarlarken çok şekilli metotlar kullanmak, değişen durumlara kolaylıkla uyum sağlayabilecek bileşenler yaratmayı sağlar. Tiplere bağlı alternatif durumlarda ilgili metot koşullu deyimlerle test edilerek çağrılabilir. Ancak bu durumda değişen koşullarda, bu testi gerçekleştiren sınıfın da yapısının değiştirilmesi ve yeniden derlenmesi gerekecektir. Bunun önüne geçebilmek için davranışın değişebileceği tiplere sorumluluk, çok şekilli metotlar kullanarak atanır. Kahve sitesinde kredi kartından onay almak için farklı programlar kullanılabilir. Gelecekte yeni bir kredi kartı tipi de sisteme eklenebilir. Bu problemi çözmek üzere yazılım ile kredi kartı onay programları arasında bir ara yüz oluşturulur. Tüm kredi kartı tiplerinde yer alan ve aslında aynı işleri yapan onay fonksiyonları çok şekillidir. Eğer sistem tek bir kredi kartı sistemi kullansaydı, çok şekilliliğe gerek olmadan sadece tek bir adaptör sınıfı koymak yeterli olurdu.

Yapay Sınıf (Pure Fabrication) Daha önceden bahsedilen uzman kalıbının getirdiği çözümler, iyi uyum ve az bağımlılık kavramları ile çelişebilir. Bu durumda bağımlılıkları azaltıyorsa ve tekrar kullanılabilirliği arttırıyorsa gerçek dünyada var olmayan yapay sınıflar yazılımda yer alabilir. Gerçek dünyadaki varlıklar ile onları yazılımda temsil eden unsurlar arasında benzerlik bulunmaktadır. Bazı durumlarda sorumlulukların atanması diğer kalıplara ters düşebilir. Bu gibi durumlarda temel olarak birbirine benzeyen işlevler bir sınıf olarak toplanarak gerçek dünyada var olmayan yapay sınıflar yaratılabilir. Nesneye yönelik sistem tasarımında yazılım sınıflarını tasarlamak için gerçek dünyadaki kavramlardan yararlanılmaktadır. Ancak uyum ve bağımlılık gibi problemlerin üstesinden gelmek için benzer işlevler, gereğinden fazla kullanılmamak şartıyla bir sınıf içinde toplanabilir. Yapay sınıfları gereğinden fazla kullanmamak esastır. İşlevsel programcılar sistemi gerçek dünya varlıklarına ayırmak yerine işlevlere göre ayırırlar. Çok fazla kullanılan yapay sınıflar yazılımı gerçek dünyadan uzaklaştırır ve anlaşılırlığını azaltır. Ayrıca sınıflar arası bağımlılığı da arttırır.

Dolaylılık-Arabirim (Indirection) Kolaylıkla değişebilecek yapılar arasındaki bağımlılığı azaltmak, yeniden kullanılabilirliği arttırır. Değişebilecek iki birim, bileşen veya servis arasındaki sorumluluklar bir arabirim nesnesine atanarak dolaylılık sağlanır. Uygulamalarda dolaylılığı arabirim nesneleri sağlar. Çok şekillilik özelliği de olan bu nesneler dış değişimlerden etkilenmemeyi sağlar. Örnek olan kahve sitesinde, kredi kartı onaylama hizmetinin dışarıdan alınmaktadır. Değişik kredi kartı kuruşlarının değişik onay mekanizmaları bulunmaktadır. Ancak uygulama açısından önemli olan sadece kredi kartı onay sorumluluğudur.

Değişimlerden Korunma (Protected Variation) Dikkat edilmesi gereken tasarım prensiplerinin sonuncusu değişimlerden korunmayı esas alır. Bir sistemdeki her bir alt sistem hatta her bir nesnede değişimler ve kararsızlıklar olabilir. Bunların diğer birimlere etkisi minimum seviyede tutulmalıdır. Birimlerdeki değişikliklerin birbirlerini en az etkilediği tasarım, değişimlere açık ve kararsız noktaların etrafında sorumlulukların ara yüzlere atanmasıdır. Bu sayede birimler değişimlerden korunabilir, kararlı sistemler oluşturulabilir. Dolaylılık kalıbında örnek olarak verilen çok şekilli arabirim nesneleri, kahve sitesi sistemini dışta olabilecek değişimlere karşı korumaktadır. Kredi kartı onay sistemleri değişse de, yenileri de eklense tasarlanan sistem bu değişimlerden etkilenmeyecektir. Sistem için gerekli olan onay alma sorumluluğu gerçekleştirilecektir.

Ürün ekleme işleminin ardışıl diyagramı

Özel kahve siparişi işleminin ardışıl diyagramı