BT Güncem

Şirketiniz İçin SOA

2011-05-02T12:19:00.001+03:00

Günümüz iş ortamı hiç olmadığı kadar rekabetçi. Yaratıcı iş modelleri, geleneksel ve yeni nesil rakipler, hizmet kanallarının çeşitliliği, sürekli artan kalite ihtiyacı, yeni uyumluluk gereksinimleri ve artan maliyet baskıları CEO’ların gündemini sürekli olarak meşgul ediyor. Sürekli yeni fikirler üretebilen ve fikirlerini çok hızlı markete sunabilen, esnek, çevik ve tepkisel bir şirket olabilmek her CEO’nun hedefi. İçsel ya da dışsal dinamiklerden doğacak taleplerin hayata geçirilebilmesi için de zaman eskiye görece çok daha kısıtlı. Oysa, yeniliklerin zamanında pazara sunulamaması çoğu kez pazar kaybıyla eşdeğer.

Tüm bunlar, doğal olarak fikirleri hızlıca hayata geçmesini sağlayacak teknolojilere olan ihtiyacı ve bu teknolojileri sunmakla görevli IT birimleri üzerindeki yükü hiç olmadığı kadar arttırmaktadır. Doğru teknoloji kullanımının stratejik önemi giderek artmakta ve dijital iş dünyası ile gerçek dünya arasındaki sınırlar giderek ortadan kalkmaktadır.

Dolayısıyla, artık şirketler içerisindeki IT departmanları, İş departmanları ile çok daha uyumlu ve birebir çalışmak durumundadır. IT departmanlarının taleplerin sürekliliği ve artan yoğunluğu ile başa çıkabilen, gelen talepleri hızlıca ve kurum içerisinde en az etki ile hayata geçiren bir yapıya adapte olması için yeni yaklaşımlar gerekmektedir. Servis odaklılık yaklaşımının mimari yansıması olan Servis Odaklı Mimari (SOA: Service Oriented Architecture) işte bu değişen iş ortamının gereklerini karşılamak için ortaya çıkmış, bir kurumsal mimari modelidir.

Forrester ve Gartner gibi firmalarca yürütülen araştırmalar SOA’den vaad edilen sonuçları alabilen firmaların, SOA’i bir kurumsal mimari modeli ve stratejik dönüşüm yaklaşımı olarak ele alan firmaların etkin sonuçlar elde edebildiğini gösteriyor. SOA’nin ciddi bir dönüşüm gerektirdiği, ancak aynı zamanda küçük, dikkatli adımlarla giden ve artarak ilerleyen bir süreçle ele alınması gerektiği muhakkak. SOA’nın vaad ettiği faydaların, gerçekleştirim sürecinin giderek olgunlaşmasıyla artarak devam ettiği göz önüne alınırsa, SOA’i sadece bir teknoloji olarak algılayıp, stratejik bir vizyondan yoksun olarak yola çıkan firmaların, büyük resmi kaçırmaları ve beklenen faydaları görememeleri, doğal bir sonuç olarak algılanmalıdır.

Bu yazıda servis odaklılık kavramları, iş dünyasına yansımaları ve stratejik SOA dönüşümlerinin nasıl ele alınması gerektiği üzerinde durulmuştur.

Servis Nedir?

Servis odaklı yaklaşımının temeli, doğal olarak servis kavramıdır. Bir servis, tutarlı bağlam çerçevesinde, birbirine uygun bir gurup tekrarlanabilir operasyondan oluşan, iyi tanımlanmış standard bir arabirime sahip, kavramsal bir bileşen olarak tanımlanabilir.

Dijital servisler gerçek dünyadaki oluşumların iyi tariflenmiş birer yansıması gibidir. Hemen hemen herkesin elektirik, su veya iletişim sağlayan şirketler ile bir müşteri olma hikayesi olmuştur. Bu firmalara işlemleriniz için uğradığınızda sizi “Müşteri Hizmetleri Birimi”’ne yönlendirirler. “Müşteri Hizmetleri Birimi” müşteriler için olası tüm operasyonları tek noktadan sunarak genel işleyişte bir verimlilik hedefler. Bu birimi SOA’de bir digital servis olarak tarifleseydik, “Müşteri Servisi” yaratıp, bu servise bağlı olarak da “Müşteri Bilgilerini Getir”, “Yeni Müşteri Yarat”, “Müşteri Bilgilerini Güncelle”, “Abonelik Sonlandır” gibi uygun operasyonlar tanımlayabilirdik.

Daha teknik bir örnek olarak bir yazıcı ünitesinin işlevlerini servis olarak tanımlamayı kullanabiliriz. “Yazıcı Servisi” muhtemelen “Belgeyi Yazır”, “Duraklat”, “İptal Et”, “Kapan”,”Açıl”,”Uyku Moduna Geç” gibi operasyonlar içerecektir.

Gerçek dünyada bulunan nesneleri bir servis olarak kavramlaştırmanın en kolay yolu, o şeyi bir kara kutu olarak düşünmek ve dışarıdan aldığı direktif ve bunlara cevaplarını birer operasyon olarak tanımlamaktır. Örneğin bir iş biriminine organizasyon yapısı, iş süreçleri ve benzeri karmaşık yapılarından sıyrılarak dışarıdan baktığımızda ne gibi işlevleri yerine getirdiğini kolayca servis olarak tanımlayabiliriz.

SOA’nin ortaya çıkışına yol açan en büyük neden, sık yaşanan değişimlerin etkilerini minimize etmek gayreti olarak tanımlanabilir. Bir başka deyişle, değişikliğe gittiğiniz bir nesnenin zincirleme değişiklikler reaksiyonuna yol açmasının önünü kesmek çabası olarak da nitelendirilebilir. Eğer bir bileşenin kendi görevlerini yerine getirmesi için bir diğer bileşenden faydalanması gerekiyor ise, bu ilişki bir bağlanım (coupling) olarak nitelendirilir. Satış departmanının bir satış işlemini tamamlaması için stok, lojistik ve muhasebe gibi departmanlara duyduğu ihtiyaç bir bağlanım örneğidir. Lojistik deparmanının mal teslimi için kabul formlarında yapacağı değişikliğin satış departmanı tarafından öğrenilmesi ve kendini buna göre adapte etmesi çalışması ise değişim etkisine (change impact) iyi bir örnektir.

Bir başka bağlanım örneği olarak iş süreçlerinin içerisine dahil edilen bir tedarikçi firma düşünün. İş süreçlerinde bu tedarikçi firmaya ihtiyaç duyan her şirket içi iş birimi ile tedarikçi arasında bir eşleme oluşturacaktır. Şimdi bu eşleme ilişkisinde doğal olarak tedarikçi ile olan ilişkiler, tedarikçinin gereksinimleri temin etme şekli (formlar, sipariş alma, durum takibi vb) ve diğer faktörler önemli olacaktır. Markette alternatifler oluşması ile tedarikçi sayısının zamanla arttığını düşünün. Her tedarikçi yeni ilişkiler, formlar, iş süreçlerini beraberinde getirecektir. Bir tedarikçinin değiştirilmesi zorunluluğu doğduğu zaman,o tedarikçi ile uyumluluğunu pekiştirmiş tüm iş birimlerinden homurtular yükselecektir.

Klasik yaklaşımda mevcut tedarikçiler ile sıkı bir ilişki içerisinde bulunulduğundan, her entegrasyon noktasında her yeni tedarikçi ile bir adaptasyon süreci yaşamanız zorunluluğu vardır. Bu adaptasyon için harcayacağınız enerji değişim etkisine bir başka örnek teşkil eder Değişim etkilerinin yüksek olduğu bir şirkette alınan her karar, yapılacak her değişiklik büyük efor ve zaman gerektireceğinden, şirketin hareket kabiliyeti doğal olarak kısıtlanır. Böyle bir durumda şirketin esnekliğinden ve çevikliğinden söz edilemez.

SOA, bu durumdan kurtulmak için bağlanım ilişkisinin gerçekleştirimler yerine sözleşmeler üzerinden kurulması ilkesini getirir (gevşek bağlanım). Servisler amaçlarını, sundukları yetenekleri, servisin nasıl kullanılacağını, mesaj yapılarını ve diğer özelliklerini bir servis sözleşmesi ile olası istemcilere sunarlar. Servisi alan taraf yani istemci, hizmetin nasıl ve kim tarafından sunulduğu ile değil, sunulmuş olan standart sözleşme ile bağımlıdır. Sözleşme yerine getirildiği sürece sözleşmenin arka planında olup biten değişiklikler istemciye yansımaz.

Tedarikçiler örneği için şirketlerin genellikle izlediği yol bir satın alma departmanı kurup iş birimlerinin taleplerinin standard yollar ile toplamaktır. Yeni tedarikçi ekleme ya da tedarikçi değişikliği örneğini ele alacak olursak servis odaklı bir şirket tedarikçi değişikliğini hemen hemen hiç hissetmeden, sadece satın alma biriminde küçük adaptasyonlar ile yapabilecektir. İşte bu SOA’nin vaad ettiği esneklik ve çevikliğin en önemli örneklerinden birisidir.

IT içinden bir örnek verecek olursak, "mainframe" uygulamaları gibi geleneksel uygulamaların açık sistemlere taşınması sırasında oluşacak etkiyi ele alabiliriz. Gerçekten de bu örnek pek çok CIO’nun başını ağrıtan bir sorundur. Tüm uygulamalar baştan sona günün gereklerine göre yeniden yazılabilir. Ancak değişmeyen tek şey değişim olduğundan, bir süre sonra yeni teknolojilerin ortaya çıkması ile bu teknolojilere adaptasyon gerekeceği aşikardır. Bu durumda oyunu tekrar baştan kurup, yeni baştan her şeyi ele almak gerekecektir. SOA bize bu noktada kavramsal düzeyde stabil olanı tanımlamayı (Servis Sözleşmeleri) ve tüm bağımlılıkları değişmesi muhtemel bileşenler yerine, daha stabil kavramlara doğru yapmamız gerektiğini söylemektedir. Bir yazılımın arabiriminin (servis ve operasyon tanımları), arabiriminin nasıl gerçekleştiğinden (operasyonların programlama dili ile kodlanması) daha stabil olduğundan biliyoruz.Bu sebeple, gerçekleştirimler yerine arabirimlere kurulacak bağlanım ilişkileri, bağımlı olan taraftaki değişiklik etkisini azaltır. Şu halde, SOA’e göre yapılacak şey aşikar olarak tüm bağımlılıkları iyi tanımlanmış servis arabirimleri üzerine çekerek arka plandaki değişiklikler için hareket kabiliyeti kazanmaktır. Bu sayede servislerinizin gerçekleştirimlerini bugün açık sistemler üzerine taşırken, yarın bulut sistemlere taşımanız ve arka plan kodlarınızı yenilemeniz hissedilmeyecek bir etki ile gerçekleşebilir.

SOA oluşturma stratejisi olarak servis sanallaştırma (Service Virtualization) ve servis otobüsü (Enterprise Servise Bus) gibi taktikler kullanmanın kurumsal değişimlerde etki indirgemenin en önemli araçlarından olduğunu da konuya yakın olan okuyucular için bir not olarak düşelim.

Servis Odaklı Dizayn Prensipleri

Service odaklılık, bir dizi dizayn prensibinin uygulanmasını birlikte getirir. Bu yazının amacı her ne kadar bu prensiplerin detaylarına girmek olmasa da konunun daha iyi anlaşılması açısından genel kabul görmüş bir dizi prensibe değinmekte fayda var.

- Servis Sözleşmeleri (Service Contracts) : Servisler amaçlarını, sundukları yetenekleri, servisin nasıl kullanılacağı, mesaj yapılarını ve diğer özelliklerini gösteren bir servis sözleşmesi ile sunarlar. Bir servisi kullanacak her türlü servis istemcisi bu sözleşmeye göre hareket eder. Servis sözleşmeleri istemciler tarafından kolayca yorumlanabilir ve standart şekilde olmalıdırlar.

- Gevşek Bağlanım (Loose Coupling): Servis istemcilerinin servise olan bağımlılığı sadece servis sözleşmesinedir. Servisin iç işleyişinin nasıl olduğu, nasıl gerçekleştirildiği servis istemcilerini bağlamaz. Bu ilke gevşek bağlanım olarak adlandırılır.

- Kavramsallaştırma (Abstraction – Conceptualization): Kavramların, özelliklerinin ve davranışlarının tanımlanmasına biz kavramsallaştırma diyoruz. Bir başka deyişle kavramsallaştırma, bir servisin, servis olmasını sağlayan şeylerin tanımlanmasıdır diyebiliriz. Kavramsallaştırma yapılırken servis isimlendirmesinin ve servis içerisinde tanımlanan yeteneklerin birbirleriyle uyumu da (cohesion) son derece önemlidir. Bir servisin tanımlanması esnasında (encapsulation) yine servis istemcilerini ilgilendirmeyen gereksiz ayrıntıların sözleşmeye konmaması (information hiding) dikkat edilmesi gereken bir başka husustur.

İyi tanımlanamamış servislerin ideal formlarına kavuşuncaya kadar değişiklikler görmesi beklenen bir durumdur.Bu sebeple tanımlamalar dikkatlice ve ideal durumlarına göre yapılmalıdır.

- Yeniden Kullanım (Reuse): Çalışma mantığı servislere ve operasyonlara dağıtılarak yeniden kullanımlarının özendirilmesi.

- Keşfedilebilirlik (Discoveribility): Servis sözleşmeleri kullanımı beklenen hedef kitle tarafından kolayca erişilebilir olmalıdır. Bu nedenle, servis sözleşmeleri hedef kitle tarafından erişilebilen servis kayıt defterlerinde kayıt altına alınarak olası istemciler tarafından keşfedilebilmesi sağlanır.

- Otonomi (Authonomy): Servisin yeteneklerini kesintisiz ve güvenilir bir şekilde sunabilmesi için kullandığı kaynaklar üzerinde tam otoritesi olmalıdır.

- Birleştirebilirlik (Composibility): Servisler başka büyük problem çözümlerinde kullanılabilirler. Bileşimin boyu ve büyüklüğüne bakılmaksızın servisler aktif çözüm bileşenleri olarak tüketilebilirler.

- Durumsuzluk (Statelesness): Durum servis operasyonlarının aynı istemci tarafından ardışıl kullanıldığı durumlarda iki operasyon kullanımı arasında istemci kullanımına özel verilerin saklanmasına verilen addır. Bu, servisin çalışırlığını ve genişleyebilirliği etkileyebileceğinden servislerin mümkün olduğu kadar durumsuz tasarlanması gereklidir.

SOA prensipleri sadece teknoloji odaklı düşünülmemelidir. Yukarıda geçen tüm prensipler iş dünyası da dahil etkileşim içerisinde bulunan nesnelerin bulunduğu her ağ için uyarlanabilir ve kullanılabilir prensiplerdir.

İş Yaşamında Servis Odaklılık

Yüksek düzeyde iş uzmanlığı gereksiniminin olduğu bir çağda yaşıyoruz. Şirketlerin temel işlevlerine daha iyi odaklanabilmesi için, "iş süreçleri içerisinde kendi alanları dışında kalan pek çok görevde bir iş ortağı ile hareket etmesi" genel kabul gören bir eğilim.

Bu eğilim özellikle üretim sektöründe yıllardır çok ağırlıklı olarak kendini göstermektedir. Aynı yöntem hizmet sektörü tarafından da daha sonradan takip edilmeye başlamıştır. Taşımacılıktan tutun da insan kaynakları yönetimine kadar pek çok alanda iş ortaklarından alınan uzman taşeron ya da tedarik hizmetleri bugün şirketlerin iş süreçlerine çeşitli seviyelerde entegre olmuş durumda. İş süreçleriniz içerisindeki görevleri, alanında uzman bir iş ortakları ekosistemine dağıtmak, şirketinizin enerjisini ve konsantrasyonunu asıl değer yaratan işlevlerine kaydırması için mükemmel bir yol olduğu gibi, maliyetlerin düşürülmesi ve verim artışı için de aynı ölçüde önemlidir. Yeni başlangıç şirketleri için de çevrelerindeki bu ekosistemden faydalanmak, kendi bünyelerinde ancak çok uzun yıllar içinde edinebilecekleri mükemmel hizmet seviyelerini, başka şirketlerden hizmet olarak hazır halde alabilmeleri demektir.

Şirketler kendi iş süreçlerini dış kaynaklardan hizmet alarak optimize ederken, aynı zamanda başka şirket ve/veya bireyler açısından da hizmet sağlayıcı rolüne bürünmektedirler. Şirketlerin iş ortakları, müşterileri, devlet gibi ortam düzenleyiciler ve diğer partiler ile olan ilişkileri hizmet alıp vermeye dayanan bir çeşit ağa benzetilebilir.

Tek bir şirket perspektifinden bakıldığında çok daha karışık bir ağ modeli yine şirketlerin iç işleyişinde de karşımıza çıkar. Bir şirket kendisini oluşturan iş birimleri ve bu iş birimleri tarafından yerine getirilen hizmetlerin bir toplamı olarak görülebilir. Bu hizmetlerden kimileri direkt olarak müşterilere sunulurken, belki sayıca çok daha fazlası da bu hizmetlerin yerine getirilebilmesi için gerekli olan hizmetler şeklindedir. Bir otomotiv firmasını ele alacak olursak bu firmanın en temel hizmeti satış ağı üzerinden müşterilerine araç sağlamak iken, bu hizmetin yerine gelmesi için şirketin iç dünyasında satış, tedarik, üretim, muhasebe ve daha pek çok iş birimi, çok sayıda karmaşık işlevler yerine getirmektedirler.

Bu hizmet alıp verme ilişkisinde, hizmeti sunan (kurum ya da iş birimi) perspektifinden dışarıya sunulan her yetenek, amaçları, standartları ve diğer özellikleri ile tanımlandığında iş servislerini oluşturur. İş yaşamında servis odaklılık şirket yeteneklerinin, nasıl gerçekleştirildiklerinden bağımsız bir düzeyde servisler olarak tanımlanması, yayımlanması ve tüm olası servis istemcilerine etkin bir şekilde sunulmasıdır. Bir iş birimi gibi belli bir perspektiften bakıldığında dış dünyaya sunulan yetenekler ve bu yeteneklerin yerine getirilmesi için gerekli destek yetenekleri, iş servislerinin kalbini oluşturur. Bu servislerin yazılımlar olarak tanımlanması da dijital iş servislerini oluşturmaktadır. Şüphesiz ki, iş servislerini dijital dünyaya taşımak, bir şirketin yeni dünyaya adaptasyonu için şarttır. Servis odaklı bir dönüşüm, şirketlere servislerini sınırsız sayıda kanaldan, sınırsız iş ortağı ve müşterinin hizmetine sunma kabiliyeti kazandıracaktır.

Servis Tipleri

Bir şirkette var olan tüm servisler aynı seviyede değerlendirilemez. Dizayn prensiplerinden hatırlayacağınız üzere servisler başka servislerin oluşumunda katılımcı olarak yer almaktadırlar. Servisleri bu bileşim şekli açısından bir hiyerarşiye oturtacak olursak, en üst seviyede şirketin iş alanları ile bire bir eşlenmiş iş servisleri koyarken, daha alt seviyelere doğru ortak işlevsellikleri sunan servisleri, üst seviye servislerin oluşumu için teknik destek veren uygulama servislerini ve altyapı görevleri için altyapı servislerini konumlandırabiliriz.

Servisler üst seviyeye doğru gidildikçe, alt seviye servislerinin bir kompozisyonu ile oluşurken, alt seviyelerde daha fazla atomik yani başka servise ihtiyaç duymadan çalışan bağımsız servisler göze çarpar.

İş servisleri, bir şirketin yeteneklerinin (iç ve dış) dijital dünyaya birebir yansıması olarak algılanabileceğinden, SOA dünyasındaki en önemli servisleri oluştururlar. İşin aslı daha alt seviyedeki servisler hazırlanmadan iş servislerinin oluşturulabilmesi de zordur. Ancak iş departmanları ve IT’nin bir masa etrafında konuşacağı, servis seviyelerinin iş indikatörleri ile eşleşeceği servisler ağırlıklı olarak iş servisleri olacaktır.

SOA Sadece Servisler Dünyasından mı İbaret?

Kurumsal SOA projelerinden bahsedilirken, SOA kavramlarının içerisine çoğunlukla başka mimari stiller, eğilimler ve teknolojilerin de dahil edildiğine şahit olabilirsiniz. Bunun sebebi SOA’nin yeni nesil yaklaşımlar için bir temel teşkil etmesi, çoğu için katalizör olmasıdır. SOA şirket içerisindeki dağıtık yeteneklerin iyi tanımlanmış arabirimler olarak, standard yöntemler ile kullanıma sunulmasıdır. Kuruma adapte edilecek her yeni yaklaşım bu yeteneklerden en efektif şekilde faydalanma yoluna gidecektir.

Kurumsal çapta veya daha küçük çaptaki projelerde uygulanan katıksız tek bir yaklaşımdan bahsedilemez. Çoğunlukla çeşitli teknolojiler ve mimari stillerin uyumlu bir bileşimi bir arada uygulanır. SOA genellikle uygulanan yaklaşımların en öne çıkanı olmasından dolayı, bir şemsiye görevi gören ve anıldığında adı bir kaç yaklaşımı daha bir arada düşündüren bir kavram.

Bu yaklaşımların en önemlilerinden biri olan ve genellikle SOA ile birlikte anılan süreç yönelimli mimari (BPM: Business Process Management) bir sistemi süreçler, alt süreçler ve aktiviteler olarak görür. Servisleri bir sistemde bulunan yeteneklerin tanımlanması ve kullanımı için etkin bir yöntem olarak tanımlarsak, süreçler sistem içindeki bu servislerin ve iş gücünün orkestrasyonudur diyebiliriz. Bir süreci oluşturan aktiviteler, sistem içerisinde bulunan servis operasyonları tarafından yerine getirilir. Bir sistemin içerisinde bulunan tüm yeteneklerin kataloglanmış servisler halinde bulunması, süreçlerin oluşturulmasını ve hayata geçirilmesini son derece kolaylaştırır. Bir kurumda süreçlerin hazır halde olması halinde ise (en azından kavramsal düzeyde), sistemde gereksinim duyulan servislerin daha rahat tespit edilebilmesini sağlar. Bu nedenle bu iki yaklaşımın hemen hemen her zaman bir arada kullanımı son derece doğal ve gereklidir. Çok beğendiğim bir analoji bu iki yaklaşımı fıstık ezmesi ve reçele örneği ile ele almaktaydı. Ayrı ayrı da tüketebilirsiniz ancak bir arada mükemmel olurlar.

Yazılımlar açısından bakıldığında süreç yönelimli mimari iş akışı mantığının gömülü kod parçalarından ve insanların zihinlerinden (ya da masalarına asılı post-it’lerden) sıyrılarak tanımlı ve kontrollü bir şekilde işletilmesidir. Yazılımların sadeleşmesini sağladığı gibi, yazılımları kullanan insan gücünün de etkin kontrolünü, takibini ve bilgilendirmesini sağlar.

Bir sistemdeki iş süreçleri, genellikle uzun süreli olup, süreç içindeki aktiviteleri ve insan teknoloji etkileşimlerini kontrol eder. Bir satış sürecini ele alacak olursak sipariş alma, ödeme alma, tedarik etme, muhasebeleştirme, lojistik gibi alt adımlar bazen aylara yayılmış bir zaman diliminde tamamlanabilir.

SOA ile giderek daha fazla birlikte anılmaya başlanan Olay Yönelimli Mimari’nin (EDA: Event Driven Architecture), eskiden beri pek çok uygulamada kullanılan bir stil olduğu halde, kurumsal mimari düzeyinde etkisinin artması daha yakın zamanlarda olmuştur. EDA ve SOA’nin bir arada bulunduğu stil kimi yazarlar tarafından SOA 2.0 olarak adlandırılmaya başlanmıştır.

Ancak başta da söylediğimiz gibi mimari stiller çoğu zaman bir arada uygulanabilirler ve bu açıdan bakıldığında kafa karıştırıcı numaralandırmalar yerine bir mimaride uygulanan yaklaşımları tek tek belirtmenin çok daha açıklayıcı olacağı söylenebilir. Bu tarz isimlendirmelerin teknik gerekçelerden çok pazarlama amaçlı türetildiğini düşünüyorum.

EDA, sistem içindeki bileşenlerin , aldığı olay yada olaylar bildirilerine tepkisel olarak aksiyonlar işletebildiği bir mimari stildir. Sistem içerisinde oluşan olaylar, olay kaynakları tarafından yayınlanır ve olay gözlemcilerine ulaştırılır. Dinleyici konumundaki olay gözlemcileri oluşan olaylar kendilerine ulaştığı anda bir aksiyon alırlar. Alınacak aksiyonun ne olacağı ve işletilecek mantık olay gözlemcisinin otoritesi altındadır.

SOA bir sistemdeki yeteneklerin resmedilmesi ve kullanımının mükemmel bir yolu olarak görülebileceğinden, sistemde oluşacak olaylar sonucu alınacak aksiyonların hazırlanmasını son derece kolaylaştıracaktır. Bir mimaride EDA’nın da kullanımı sistemin daha proaktif, tepkisel ve çevik olmasını sağlayacaktır. Buzdolabınızda peynirinizin bittiğini farkedip, üzerinizi giyip marketten peynir almanız tembellik yapmak istediğiniz bir Pazar sabahında sizi sıkabilir. Buzdolabınızın peynirin bittiğini kendi kendine fark etmesi, en yakın marketten istediğiniz markayı sipariş vermesi güzel olmaz mıydı?

SOA şemsiyesi altında anılan yeni nesil yaklaşımlar ve teknolojilerin incelenmesi uzun bir konu. En önemli iki yaklaşım olan BPM ve EDA’ı kısaca ele aldıktan sonra, diğer yaklaşımlardan bazılarına da kısaca değinmek gerekir ise:

· BRM (İş Kuralları Yönetimi - Business Rule Management):

Sistem içerisindeki sık değişen iş kurallarının (örneğin vergi oranları, kar oranı, hesaplama sabitleri vb) servis gerçekleştirimlerinin içerisinde gömülü olarak tutulması yerine, ayrı bir noktada tanımlanması, kural erişimlerinin ortak bir servis üzerinden sağlandığı, kural değişikliklerinin anında tüm sisteme değişiklik gereksimi olmadan yansıtılabildiği bir yaklaşım olarak nitelendirilebilir. Bir sistemde BRM kullanımı tüm servislerin stabilitesini arttıracaktır.

· PDA (Politika Yönelimli Mimari – Policy Driven Architeture)

Sistem çalışma politikalarının yine gömülü kodlardan sıyrılarak dış bir ortamda tanımlanmasıdır. Sistem bileşenleri ve servislerin gerekli zamanlarda servisler üzerinden bu politikaları okuyarak davranışlarını düzenlemeleri hedeflenir.

· ESB (Kurumsal Servis Otobüsü)

İstemciler ile sunucular arasında bire bir bağlanım yapmak yerine, ek bir ara katman üzerinden konuşulmasını sağlayarak servis alınan noktaların istemcilerden tamamen gizlenmesi yaklaşımıdır. Bu yaklaşım, yapılan toplam bağlanım sayısını indirgeyeceği gibi karmaşık entegrasyon sorunlarını da istemcilerden gizleyecektir. İstemciler standart yöntemler ile ESB ile konuşurken, ESB geri planda farklı protokol ve servis sağlayıcılar ile haberleşebilir. Aslında “Servis Nedir?” bölümünde anlatılan iş birimleri ile tedarikçi ilişkilerinin bir satın alma departmanı standartlaştırılması bu yaklaşımın iş yaşamına uyarlanmasının güzel bir örneğidir.

· Aspect Oriented Arhitecture (Cephe Yönelimli Mimari)

Çok sayıda bileşen ya da servisi ilgilendiren ortak çalışma mantıklarının bu bileşen yada servisler içerisinde tek tek ele alınması yerine, tek bir noktada oluşturulması ve tüm ilgili noktalarda çalıştırılmak üzere otomatik enjeksiyonudur. Bu, filtreleme yöntemleri ile uygulanabildiği gibi, otomatik kod oluşturma teknikleriyle de yerine getirilebilmektedir. Servis erişimlerinde tek tek erişimi yapan istemciler hakkında güvenlik kontrolü yapmak yerine, ortak bir katman üzerinde (örneğin ESB) bu kontrollerin tamamlanarak servislerin yüklerinin hafifletilmesi ve sadece güvenli isteklerin servislere erişiminin sağlanması bu yaklaşıma iyi bir örnektir.

Stratejik Bir Yaklaşım Olarak SOA

Servis odaklı dönüşüm stratejinizi nasıl oluşturacağınıza geçmeden önce hayal gücünüzü biraz daha canlandırmak için servis odaklılık dönüşümünü tamamlamış bir şirketin yaşamını kısaca tasvir etmek istiyorum. Varsayımsal şirketimizin adı “Çevik Servisler A.Ş.” olsun ve kısaca ÇS diye analım.

ÇS şirketi, şirketin bütününü oluşturan tüm iş bileşenlerini (yeteneklerini) tanımlamış ve kategorize etmiş olduğundan, ÇS şirketi üst yönetimi stratejik kararlar alırken, şirket iş modeli haritasından faydalanarak hangi iş bileşenlerine ve iş süreçlerine etki edeceklerini rahatlıkla görebilmektedir. ÇS şirketinde bir iş bileşeni altında yatan süreçler, iş servisleri bunları destekleyen yazılımlar ve altyapılar bilindiğinden yeni stratejilerin getireceği değişiklikler bütün birimler tarafından hızlı bir biçimde algılanmakta ve gerekli değişiklikler çok hızlı projelendirilip yerine getirilebilmektedir.

ÇS şirketi yöneticileri, iş servisleri ve iş süreçleri hakkında sürekli gözlem yapma ve performans indikatörlerini sürekli takip edebilme imkanına sahiptir. Örneğin geçen ay başında yapılan sipariş alma sürecindeki iyileştirmenin, iş gücü üzerinde %10’luk bir tasarruf sağladığını görmek, şirket CEO’sunu oldukça neşelendirmiştir. İş süreçleri ve iş servislerinden toplanan bilgilerin, dengeli kurum karnesinde sürekli görünür hale gelmesi, personel performans takibini de son derece kolaylaştırdığından İnsan Kaynakları Müdürü de çok memnundur ve katıldığı tüm platformlarda geldikleri noktayı göğsünü gere gere anlatmaktadır.

ÇS şirketinin müşterilerine ve iş ortaklarına sunduğu iş yetenekleri yazılım servisleri halinde kataloglandığından pek çok kurumsal müşterisi ve iş ortakları ÇS servislerini kendi sistemlerine entegre etmiş durumdadır. En büyük kurumsal müşterilerinin siparişlerini kendi sistemleri üzerinden açmaya başladığından beri satış departmanının yükü bir hayli hafiflemiştir. Bu müşteri hesabının yöneticisi sürekli yaşadığı telefon trafiği bittiği için çok mutludur, artık müşterisine sadece haftada bir kahve ziyareti için uğramaktadır.

ÇS iş servislerini self servis kanallarından müşterilerine aracısız sunmaktadır. Yeni hazırlanan cep telefonu yazılımlarını, sadece cep telefonu ara yüzlerinin tamamlanarak mevcut servisleriyle bir ay gibi kısa bir sürede hayata geçmesi şirket CIO’sunu çok gururlandırmıştır.

CIO, tüm servislerin ESB üzeriden erişimine karar vererek ne kadar isabetli bir iş yapmış oldukları yeni muhasebe programının entegrasyonu sırasında bir kez daha görmüştür. Yeni muhasebe yazılımının servislerini, hızlıca kendi muhasebe servislerine adapte etmişler ve diğer yazılımların da hiçbir şeye dokunmamışlardır.

Stokların azalmasını takiben otomatik satın alma siparişlerinin açılır hale gelmesinden beri satın alma departmanı da, iş yükünü hafifletmiş, Satın Alma Müdürü iki senedir ertelediği tatiline nihayet çıkabilmiştir.

Şirket CEO’su, geçen hafta akşam yemeğinde bir araya geldiği, aynı zamanda şirketin de VIP müşterileri arasında yer alan bir arkadaşının, şirketin Antalya şubesine girdiğinde kendisini karşılayan Özel Müşteri Temsilcisinin kendisi hakkında sahip olduğu bilgiler ve gösterdiği ihtimam karşısında nasıl şaşırdığını son yönetim kurulu toplantısında gururla anlatmıştır. CEO'nun arkadaşı elbette yeni hayata geçirdikleri sistemde, VIP müşterilerinin şubeye girişlerinde özel müşteri temsilcilerinin otomatik olarak uyarıldığı ve bilgilendirildiğini bilmiyordur.

Bu örnek daha da uzatılabilir. Ancak bu noktadan sonra ÇS şirketini sizlerin hayal gücüne bırakırken, tüm bunların bir şirket yaşamında kazara oluşabilecek bir durumlar olmadığını vurgulamam gerekiyor. Hatta, servis odaklı olmaya karar vermiş ve tüm yazımlarını modüler servisler olarak hazırlamaya karar vermiş bir şirketin bile, doğru strateji ile hareket etmemesi durumunda arzu edilen duruma ulaşamayabileceğinin altını çizmeliyiz. Böyle bir değişimi gerçekleştirmek, yüksek bütçeli IT yatırımları ve “just do it” felsefesinden ziyade, doğru bir strateji çizmek ve bu stratejiyi sabırla uygulamaya bağlıdır. Böyle bir stratejiyi oluşturmak için ise kabaca şu adımları önerilebilir:

1. Hedefin, gidilmek istenen noktanın belirlenmesi

Stratejik bir SOA programı oluşturmada ilk odaklanılacak yer teknoloji değil, iş modelidir. Şirket için idealize edilmiş bir iş modeli oluşturmak ilk adım olacaktır. Bunun için hali hazırda bulunabilecek endüstri modellerinden ve uzman danışmanlardan faydalanılarak özelleştirilmiş modeller oluşturmak gerekecektir. İş modeli şirketi oluşturan yeteneklerin iş bileşenleri şeklinde dekompozisyonu, süreçler ve bunlar arasındaki ilişkiyi gösterir şekilde olmalıdır. Şirket için hazırlanacak bu idealize iş modeli yazılım, bilgi ve altyapı mimarilerine de yol gösterici olacaktır.

Bu idealize modeller için değer zinciri (value chain) analizleri şirketlerin en önemli süreçlerini, süreçleri oluşturan aktivitelerini (ve dolayısıyla iş servislerini) ortaya koymakta faydalı olacaktır. Ancak şirketlere daha bütünsel bakılmasına yardımcı olan ve tüm iş bileşenlerini (dışarıdan hizmet almak istencekler de dahil) ortaya koyacak, değer ağı (value net) gibi daha yenilikçi yöntemler SOA ve servislerin daha rahat tesbiti açısından daha faydalıdır.

Örneğin IBM tarafından geliştirilmiş bir değer ağı yöntemi olan “Component Business Model” yaklaşımı, şirketi oluşturan iş bileşenlerini belirlemek ve kategorize etmekte yol gösterici olabilir.

Şirket iş birimleri içerisindeki tüm yetenekler iş bileşenlerine ayrıştırılıp, bu yeteneklerin yerine getirilmesi için servis, insan kaynağı, iş süreçleri, bilgi modeli, olay- sonuç ilişkileri, teknoloji ve sağlıklı izleme ve geri bildirimler için indikatörler belirlenmelidir. Tabii bu iş bileşenleri için birer yönetişim modelinin oluşturulması da bu aşamada daha sağlıklı bir şirket için zemin oluşturur.

Tüm iş bileşenlerinde bahsettiğimiz detayda inilmesi elbette uzun bir zaman alabilir. Mükemmel form bir kerede yakalanamayabilinir. Dolayısıyla, ilk adım öncelikle şirket yeteneklerinin ayrıştırılması olup, iş bileşenlerinin ve iş bileşenleri arasındaki ilişkilerin belirlenmesidir. Bu temiz bir bakış açısı kazanmak ve yürünmesi gereken yol için fikir sahibi olmak adına yeterli olacaktır.Detaylandırma çalışmaları diğer çalışmalar ile paralel bir şekilde , zamana yayılmış olarak yürütülebilir.

SOA’de amaçlarımızdan birisi İş ve Teknoloji uyumluluğunu yakalamak olduğundan iş servislerinin, iş bileşenlerininin bir parçası olarak belirlenmesi bu yolda çok önemli bir adım olacaktır.

2. Mevcut Durumun, Bulunulan Noktanın Tesbiti

Mevcut iş, yazılım, bilgi ve altyapı mimarilerinizin anlaşılması ileriye doğru atacağınız adımların planlanması için gereklidir. Bir çok şirket mükemmel organizasyona ulaşmak için yıllardır kalite çalışmalarını aralıksız sürdürmekte olduğundan, şirketlerde kolaylıkla dokümante edilmiş iş süreçleri, iş tanımları, görev tanımları ve organizasyon yapısına erişmek mümkündür. Benzer dokümantasyona veri modelleri, yazılımlar ve altyapı içinde rahatlıkla erişilebilir.

3. Yol Haritasının Çizilmesi

Hedef iş modellerinde, iş bileşenleri arasındaki bağımlılıklar ortaya konmuş olacaktır. IT bu noktada sıkı bir çalışmayla iş servislerindeki ortak noktaların tespitini yaparak ve kurumsal politikaları da göz önüne alarak gereken ortak servisleri tespit etmeli, iş servislerinin oluşturulabilmesi için daha alt seviyedeki teknik servisler belirlemelidir. Alt seviyeli servisler fazlaca abartmadan ilk geliştirilmesi düşünülen iş servislerini destekleyecek şekilde öncelikli olarak ele alınmalıdır.

İş servisleri arasındaki bağımlılıklar bilineceğinden ve gerekli alt seviye servisler de ortaya konacağından alternatif gerçekleştirim yolları da yaklaşık olarak belirlenmiş olacaktır. Bağımlılıkların ortaya konması doğru yol haritalarının oluşturulabilmesi için şarttır.

4. Planlama

Gereksinimler ve bağımlılıklar ile ortaya konan alternatif yollardan en akıllıca olanlarının bir plana oturtulması SOA programını hazır hale getirecektir. Politik ortam gereği aksi gerekmedikçe, en bağımlı olunan servisler en öncelikli gerçekleştirilmelidir. Örneğin müşteri servisi ele alınmadan bir CRM uygulaması geliştirmeye çalışmak, muhtemelen CRM projesinde çalışanları son derece zorlayacak, CRM projesinin tekrar tekrar ele alınmasını gerektirecektir.

Yazılımların servisler haline dönüşmesi bir kerede olacak bir iş değildir; küçük ve dikkatli adımlar ile ilerlemek gerekmektedir. Bu dönüşüm esnasında, yeni servisler idealize edilmiş hedef duruma mümkün mertebe yakın hazırlanmalıdır.

Başlangıçta küçük ama etkili gerçekleştirimler seçerek, sistemlerinizi servisleriniz için seçeceğiniz protokoller ile uyumlulaştırarak başlamak hazırlanacak servislerden maksimum fayda görülmesini sağlıyacaktır. Mevcut sistemlerinizin ideal servislere adaptasyonu, muhtemelen sıfırdan yazılacak servislere göre servis sayısını daha hızlı bir şekilde arttıracak ve SOA’den edinilecek faydaların da daha hızlı görünür olmasını sağlayacaktır.

Mevcut sistemlerin SOA dönüşümlerinde en sık yapılan hatalardan biri, mevcut sistemlerin ideal servislere adapte edilmeden, birebir servislere dönüştürülmesidir. İdeal durumuna ulaşmaya çalışan bir sistem üzerinde, servisler arabirimleri ile birlikte değişeceğinden, SOA’den bir fayda beklenemez. Aksine böyle bir yaklaşımla, SOA geleneksel yazılım geliştirme yöntemlerinden çok daha külfetli bir hale gelecektir. SOA analiz ve tasarım çalışmalarınızda biraz daha özenli olmanızı bekler, bu sebeple projelerde bu safhalara ayıracağınız zamanı daha dikkatli planlamalıdır.

Yukarıda saydığımız faktörler SOA’nin değerini hızlı bir şekilde göstermesi için zorluklar yaratsa da tüm şirketteki tarafların farkındalıkları sürekli bilgilendirme ile arttırılarak SOA programları için gerekli destek sağlanabilir. SOA yolculuğu yokuş çıkan bir kamyona benzetilebilir. Zor zamanlardan sonra yolculuk çok hızlı gitmeye başlıyacaktır.

Sonuç

Yeni nesil kurumsal mimarilerin başını çeken SOA ve beraberinde BPM, EDA gibi mimari stillerin çok daha yoğun bir şekilde uygulandığını görmeye başlayacağız. Bu yeni yaklaşımlar şirket içerisinde IT’nin yerini oldukça etkilemekle birlikte, IT’nin iş geliştirme yöntemleri üzerinde de oldukça dramatik etkilere yol açacaktır ve açmaya başlamıştır.

Özellikle ülkemizde, servis odaklılık, popülerlik toz bulutu altında çok da fazla anlaşılamamış olsa da, giderek artan bir şekilde ve evrimleşerek hayatlarımızı etkilemeye, köklü değişimler yaratmaya devam edecektir. Servis odaklı dönüşümlerini tamamlayan şirketler, gelenekçi şirketlere göre çok daha hızlı hareket etme kabiliyetine kavuşacaklarından, gelecekteki market liderlerinin servis odaklı şirketler olacağını öngörmek yanlış olmayacaktır.

Başarılı bir dönüşüm yolculuğu dileklerimle.

Nesne Yönelimli Yazılımda Dizayn Prensipleri

2011-04-22T15:40:00.002+03:00

Uzunca bir süre önce yazdığım bir yazıyı güncelliğini koruduğunu düşündüğüm için aynen yayınlıyorum.

Esen Kalın .

Sistem içerisinde detaylara girildikçe olaylar gittikçe karmaşık bir hal almaya başlar ve kolaylıkla kontrolü kaybedilebilir. Walker Royce’un ”The Rational Edge”'de yayınlanan bir makalesinde yer alan şu istatistikler ilginçtir :

Yazılım projelerinde geliştirme için harcanan her bir dolarlık maliyete karşılık bakıma iki dolar harcanmaktadır
Geliştirme eforunun sadece %15’i doğrudan programlamaya harcanmaktadır

Bu istatistikler bize bakıma , geliştirmenin iki katı süre harcadığımızı söylemektedir.Açıkça bakım maliyetlerini düşürmek için bir çözüme ihtiyaç vardır.Nesne yönelimli programlama bu maliyeti azaltsa da ne yazıkki sıfırlayamamaktadır.Şu örnek olayı daha iyi kavramamızı sağlıyacaktır :

A ve B sınıfları tarafından yeniden kullanılan bir R sınıfı düşünelim.Eğer A sınıfı ; R sınıfının davranışlarında bir yenilik yada değişiklik ihtiyacı duyarsa bu aynı zamanda B sınıfını da etkileyecektir.Bu durumdayken eğer B bu yeni davranışa ihtiyaç duymazsa ne olur ? Ya da değişiklik B için olumsuz bir durum yaratıyorsa ? Bu durum yeniden kullanımın olduğu ancak bakımın sorun olduğu bir örnek teşkil eder.

Nesne yönelimli programlamanın en önemli avantajı sağladığı yeniden kullanım olanaklarıdır.Ancak sırf bu amaç uğruna körü körüne başlanılan projeler bir süre sonra rahatlıkla kördüğüm halini alabilir.Yukarıda bahsedilen problemin çözümü için pek çok yol öne sürülebilir , ancak kuşkusuz en doğru yaklaşım bunun bir dizayn sorunu olduğunu kabul etmektir.Doğru prensipler doğrultusunda geliştirilen dizaynlar bu tip problemleri en aza indirirler.

Sınıf Dizayn Prensipleri

Dizayn prensiplerinin İlk bölümünde sınıf dizaynı ile ilgili prensipler ele alınmıştır.Ancak bu prensipler modul gibi diğer bileşenlere de uygulanabilir prensipler olarak algılanmalıdır.

Açık Kapalıdır Prensibi (The Open Closed Principle - OCP)

Bu prensip kısaca “bir modul genişlemeye açık ancak değişikliğe kapalı olmalıdır” şeklinde özetlenebilir.Belki de tüm prensiplerin en önemlisi olan bu prensip “Bertrand Meyer”’in çalışmalarına dayanmaktadır.Prensip kısaca kodlarımızı değişikliğe gerek kalmadan genişletebilmemiz gerektiğini söyler.Bir başka deyişle modulümüzün yeteneklerini var olan kodları değiştirmeden geliştirebilmeliyiz.Bu ilk başta biraz karışık görünse de bu prensibi yerine getirebilmek için çeşitli tekniklere sahibiz.Bu tekniklerin tümü de aslında nesne yönelimli programlamanın temel prensiplerinden soyutlama’ya (abstraction) dayanmaktadır.Örneğin elimizde bulunan modem sınıfımız “Hayes” ve “Ernie” tipi modemler için kodlanmış olsun ve methodlarına dışarıdan belirtilen modem tipine göre davransın.

Bu dizaynda sisteme eklenecek her yeni modem tipi var olan sınıfın değişikliğini gerektirecektir.Ancak modem sınıfını soyut hale getirerek bu sorunu kolaylıkla aşabiliriz.Bu durumda sisteme eklenecek her yeni modem tipi , modem soyut sınıfını gerçekleştirecek ve sadece kendi kodunu içerecektir.Ancak bu durum mevcut sınıfların hiçbirine dokunulmadan yerine getirilebilecektir.

OCP prensibi mimari olarak bize değiştirmeden geliştirebileceğimiz moduller kurma olanağı sağlar.Bu erişilmesi oldukça güç bir hedeftir.

Liskov’un Yerine Koyma Prensibi(The Liskov Substitution Principle - LSP )

Bu prensip Barbar Liskov tarafından ortaya konmuştur.Kısaca alt sınıfların üst sınıflara uygun olması gerektiğini söyler.İlk bakışta nesne yönelimli yazılımın bunu doğası gereği sağladığı düşünülse de durum biraz daha karmaşıktır.Bu prensip aynı zamanda temel sınıfın gösterdiği davranışların alt sınıflar tarafından da aynen yerine getirilmesi gerektiğini söyler.Durum bir örnekle daha kolay anlaşılabilecektir.Örnek olarak elips ve daire şekillerini ele alalım.Daire aslında elipsin bir cinsidir , tek farkı dairede ; elipsin iki merkezinin tek noktada buluşmasıdır.

Durum sınıfların özellikleri ve davranışları devreye girdiğinde biraz daha karışık bir hal alacaktır.Ekli şeklide görüldüğü üzere elipsin üç niteliği vardır.İlk ikisi merkezleri , üçüncü nitelik ise eksenin boyunu gösterir.Eğer daire elipsten türerse bu üç niteliğe de sahip olmak zorundadır.Ancak daire sadece merkez noktası ve çapa ihtiyaç duyar.

Elips’in merkezleri belirleyen setFoci metodu muhtemelen şu şekilde olacaktır :

Public void setFoci(Point a , Point b) {

focusA = a;

focusB = b;

}

Daire ise tek merkeze sahip olağından bu methodu şu şekilde değiştirebilir :

Public void setFoci(Point a , Point b) {

focusA = a;

focusB = a;

}

Bu durumda daire fazladan gereksiz bir niteliğe sahip olsa da her iki sınıfta görevlerini tam olarak yerine getirebilecektir.Sistem sorunsuz gibi görülebilir.Ancak bu durum sadece elips ve daireden oluşan bir sistem söz konusu olsa geçerli olurdu.Ne yazıkki bu sınıflar başka sınıflar ile bir arada çalışmak zorundadırlar ve sundukları her davranış ya da nitelik dış dünya ile bir kontrat niteliği taşır.Ve bu kontrat hiç bir şekilde bozulmamalıdır.Örneğin dışarıda şu şekilde bir method bulunduğunu var sayalım.

void f(Ellipse e){

Point a = new Point(1,0);

Point b = new Point(-1,0);

e.setFoci(a,b);

e.setMajorAxis(3);

assert (e.getFocusA() == a);

assert (e.getFocusB() == b);

assert (e.getMajorAxis() == 3);

}

Bu durumda method elipse ile çalıştığını varsayıyordur ve elips sınıfı kullanıldığı sürece bir hata üretmez.Ancak bu methoda elips yerine daire gönderildiğinde hataya yol açacaktır.Elips sınıfı setFoci() metoduyla açıkca bir kontrat imzalamıştır ve bu kontrat gönderilen belirtilen noktaların sınıfın iki noktası olarak belirleneceğini söyler.Ancak daire sınıfı bu kontratı açıkca ihlal etmektedir.

Neyazıkki LSP ihlalleri sistem içerisinde oldukça geç farkedilir .Örneğin elips / daire örneğinde olduğu gibi ilgili method daire ile deneninceye kadar bu durum ortaya çıkmaz.Durumun telaffisi eğer orjinal sınıfların değişikliği de zor bir durumda iken farkedilirse oldukça istenmeyen şekillerde çözülür.Sıklıkla rastlanılan bir şekilde if/else – switch/case gibi ifadelerle durum çözülmeye çalışılır.

void f(Ellipse e){

if(typeID(e) == typeID(Ellipse) ){

Point a = new Point(1,0);

Point b = new Point(-1,0);

e.setFoci(a,b);

e.setMajorAxis(3);

assert (e.getFocusA() == a);

assert (e.getFocusB() == b);

assert (e.getMajorAxis() == 3);

}else{

Point a = new Point(1,0);

Point b = new Point(-1,0);

e.setFoci(a,b);

e.setMajorAxis(3);

assert (e.getFocusA() == a);

assert (e.getMajorAxis() == 3);

}

Ancak bu gibi çözümler de OCP genellikle prensibini ihlal ederler.Yukarıdaki durumda yeni bir elips sınıfı türetildiğinde f fonksiyonunun da doğruluğu kontrol edilmeli yada değişikliğe uğratılmalıdır.

Bu gibi ihlallerin ortaya çıkmaması için özellikle temel sınıfların

Kontratları iyice kontrol edilip alt sınıfların uyamıyacağı kontratları içermemesi sağlanmalı

Alt sınıfların üst sınıf kontratlarına harfiyen uyması sağlanmalı

Sistemde bir başka temel sınıfın varlığının gerekliliği iyice sorgulamalıdır.

Bağımlılığın Çevrimi Prensibi ( The Dependency Inversion Principle - DIP )

Soyut eşleme (abstract coupling) olarak da adlandırılan bu prensip kısaca bileşenler arası eşlemelerin (ya da bağımlılıkların) somut sınıflar üzerinden değil soyut sınıflar üzerinden yapılması gerektiğini söyler.Eğer OCP prensibini nesne yönelimli mimarinin hedefi sayıcak olursak DIP prensibini bunu sağlıyacak temel mekanizma olarak adlandırabiliriz. COM,CORBA,EJB gibi bileşen teknolojileri gücünü bu prensipten alırlar.

Procedürel dizaynlar bir parça bağımlılık yapısı gösterirler.Üst seviye moduller uygulamanın üst seviye politikalarına bağımlıdırlar.Bu politikalar uygulamanın alt seviye modulleri , onların implemantasyonu ile ilgilenmezler.Ancak procedürel yapılar bunun tam tersi yukarıdan aşağıya doğru bir bağımlılık gösterir.(Örneğin C dilinde hazırlanmış bir grafik kütüphanesi , alt seviyelerde grafik objeleri içeren detay kütüphaneler , sistem kütüphaneleri vb. bir yapı düşünün).

Nesne yönelimli mimariler ise bambaşka bir bağımlılık yapısı gösterirler.Üst seviye moduller soyut sınıflar ile politikaları içerirken alt seviyelere gittikçe bu politikaların gerçekleştirimleri elde edilir.Bağımlılık tam tersine dönmüş gibidir.

DIP bize genişleyebilir ve esnek bir mimari kurma olanağı sağlar.Geliştirmenin ilk safhalarında gereksiz hatta külfet gibi görünen bu prensip ilerleyen yaşam evrelerinde hayat kurtarıcı olabilir.

Örneğin C dilinde yer alan string.h kütüphanesi somut fakat esnek olamayan bir yapı sergiler.ANSI standarlarında oldukça iyi çalışan kütüphane projenin örneğin UNICODE standardına dönmek istemesiyle oldukça baş belası bir durum oluşur.

DIP presinbinin uygulanmasında karşımıza çıkacak en büyük sorun nesne oluşturulmasıdır.Yaratılan soyut sınıflar üzerinden nesneler yaratılamaz.Bu durumun en güzel çözümü GOF paternleri arasında yer alan “Abstract Factory” paterninin uygulanması ile aşılabilir.

Arabirimin Ayrılması Prensibi ( The Interface Segregation Principle – ISP )

Bu prensip bize genel içerikli büyük arayüzler yerine , istemcilere yönelik pek çok arayüzün tercih edilmesini tavsiye eder.Bu prensibin özü oldukça basittir.Eğer farklı farklı istemciler için genel bir arayüz tasarlarsanız bu istemcilerin herhangi biri için gereken değişiklik pek çok yeri etkileyecektir.

Yukarıdaki örnekte servis üç istemci için methodlar barındırmaktadır.Örneğin istemci A methodları üzerinde yapılacak bir değişiklik , hiçbir ilgileri bulunmadığı halde diğer iki sınıfıda ilgilendirecek ; bu iki sınıfında yeniden gözden geçirilimesi gerekecektir.

Servisin direk parçalanması söz konusu olabileceği gibi aşağıdaki şekilde olduğu gibi servisin farklı arayüzlere bölünmesi de kullanışlı bir tekniktir.

ISP her istemci için bir arabirim yapılmasını önermemektedir.Bu prensipten bu çıkarılmamalıdır.Aksine bu durum oldukça sağlıksız ve ağır bir sistem yaratır.Bunun yerine istemciler kategorilerine ayrılmalı ve arabirimler bu kategoriler doğrultusunda yaratılmalıdır.

Birleşik Yeniden Kullanım Prensibi ( The Composite Reuse Principle - CRP )

Bu prensip diğer prensiplere göre daha tartışmalı ve kesin olmayan bir prensiptir.Alt sınıf methodlarının gurplar halinde birbirine benzeştiği durumlar için uygun bir taktik sayılabilir.Bu prensibin temel fikri nesne yönelimli programlamada polimorfizm’e kalıtım yerine birleştirme ile de gidilebileceğidir. Polimorfizm alt sınıfların ana sınıftan farklı özellikler gösterebileceğini belirten deyimdir.

abstract class Animal {

  abstract void talk();

Class Dog extends Animal {

  public void talk() {

    System.out.println("Scooby dooby Doo");

Class Cat extends Animal {

  public void talk() {

    System.out.println("Meow....");

Örnek kodda “Animal “ ana sınıfının alt sınıfları “Dog” ve “Cat” ana sınıftan farklı konuşma davranışları sergilemektedir , başka bir deyişle polimorfik yapıdadırlar.Yine bu örnekte kalıtım özelliği ile kolayca polmorifzm’e ulaşılmıştır.Ancak pratikte bazı durumlarda bu özellik esnek olmıyan ve etkisiz yapılar kurulmasına yol açabilir.

Örneğin bir bordro sistemi tasarladığınızı varsayalım.Yılbaşına yakın bir zamanda göreviniz personelin ikramiyelerini hesaplıyacak bir sistem hazırlamak olsun.Şirketin üç tip personeli kalıcı ; geçici ve yarı-zamanlı olsun.

Muhtemelen ilk dizaynınız yukarıdaki gibi olacaktır.Belli bir zaman sonra müdür yarı zamanlı personelin prim hesaplamasını değiştirmek istesin.Bu durumda tek yapacağınız yarı zamanlı personel sınıfında primHesapla methodunu basitçe üzerini ezerek değiştirmek olacaktır.

Bir süre sonra müdür danışman olarak çalışanların prim hesaplama şeklini yarı zamanlı personel gibi değiştirmek istesin.Bu durumda :

Yarı zamanlı personelin bir alt sınıfı olarak danışman sınıfı yaratabilirsiniz.Ancak bu sınıf hiyerarşisinde bir sorun olacaktır.Bu dizayn olmadığı halde danışmanların ; yarı zamanlı personel olduğunu ilan eder.Örneğin ileride danışmanlara ; kalıcı personel oranında prim verilmek istendiğinde sınıf hiyerarşisi bunu zorlaştırır.

Danışman sınıfını direk çalışan sınıfının alt sınıfı olarak yaratabilir ve primHesapla metodunu yarı zamanlı personelden kopyalabilirsiniz.Ancak bu yeniden kullanım hedefimizi zedeler ve aynı kodun çift olarak yaratılmasına yol açar.

Burada hata çalışan sınıfının tasarlanması sırasında ortaya çıkmıştır.Prim hesaplama metodunun sık değişmeyen ve herkeze uygun bir method olduğu düşünülmüştür.Ancak gerçekte bu method her çalışan tipine göre değişiklik gösterebilir ve oldukça sık değişebilir bir method’dur.Kalıtım yalnızca alt sınıfların üst sınıfa tam olarak uygun olacağı durumlarda kullanışlı bir yöntemdir.Ana sınıfın methodlarının sürekli olarak üzerinin ezilmesi kalıtım ilişkisini anlamsız kılar.Bu durumda üst sınıfta ; alt sınıflar gibi özelleşmiş bir sınıf olmaktan öte gidemez.

Bu durum soyut bir prim hesaplama sınıfı yaratılarak zarif bir şekilde halledilebilir.

Bu çözümde PrimHesalayıcı tüm çalışan tipleri için birleştirilmiş (composite) bir yapı sunmaktadır ve bu yapı oldukça esnek bir polimorfik yapı sergilemektedir.

Bu örnek CRP seçimi için oldukça uygun bir örnektir.Bu örnekte kalıtım sizi her alt sınıfta yeni bir geliştirme yapmaya zorlar.

En Az Bilgi Prensibi ( The Principle of Least Knowledge - PLK)

Bu prensip bize kullandığımız bir nesnenin içinden direk olarak başka nesnelere ulaşmamamızı salık verir.Bunun yerine sadece bildiğimiz nesne bize tüm methodları sunmalı ; iç yapısındaki başka nesnelerle ilgilinememiz gereksiz kılınmalıdır. Aksi takdirde nesnenin karmaşık yapısına kendimizi bağlamış oluruz.Aynı zamanda nesne de bir başka nesneyi dışarıya sunduğu için bir sözleşme imzalamış olur . Ekli örnekte PLK prensibine uymayan bir method ve uygun hali görülmektedir :

Hatalı	Doğru
public void test (AClass o){ AnotherClass ao = o.get(); ao.doSomething(); }	public void test (AClass o){ o.doSomething(); }

PLK’nın ana dezavantajı sınıflara pek çok ek metodun yüklenmesidir.Örnekte PLK prensibine uymak için sınıf başka bir sınıfın metodunu kendine almak zorunda kalmıştır.Bu açıkça çok yüklü ve hantal sınıfların doğmasına yol açabilir.Ancak bu durum sınıfın dışarıya somut sınıf referansları değil de arabirim referasları sunmasıyla halledilebilir.Yani kısaca bir sınıftan dışarıya verilen referaslar soyut sınıflar üzerinden olmalıdır diyebiliriz.Bu şekilde sınıfımızı bir başka somut sınıf ile eşlemeden DIP ve OCP prensiplerine de uygun olarak çözümler geliştirebiliriz.Java örneğine bakıldığında bu şekilde hazırlanmış onlarca sınıf görülebilir.

Tek Sorumluluk Prensibi ( The Single Responsibilty Principle - SRP)

Bu prensip aynı zamanda uyumluluk (cohesion) prensibi olarak da tanınır.Bu prensibi kısaca “bir sınıfın değiştirilmesi için birden fazla sebep olmamalı “ şeklinde özetleyebiliriz.Bu aynı zamanda bir sınıf birden fazla sorumluluk taşımamalı şeklinde de özetlenebilir.Çünki her sorumluluk aynı zamanda değişimin ana sebebidir.İstekler değiştiğinde o isteği yerine getiren sınıflar değiştirilerek istek yerine getirilir.Eğer bir sınıf birden fazla sorumluluk taşıyorsa , o sınıfın değişmesi için birden fazla sebep var demektir.

Örneğin alan hesaplama ve çizim methodlarını içeren bir dikdörtgen sınıfını ele alalım.Grafik ve geometri hesap uygulaması olmak üzere İki değişik uygulama bu sınıfı kullansın.Bu durumda dikdörtgen sınıfı iki sorumluluk yüklenmiş olur .Birincisi alan hesabı yapmak , ikincisi ise dikdörtgenin grafik çizimini yapmak.Halbuki bu uygulamayı kullanan uygulamalar bu fonksiyonalitenin sadece birine ihtiyaç duymaktadırlar.Bu durum iki soruna yol açmaktadır :

Geometri hesap uygulaması hiç ihtiyacı olmadığı halde çalışma sırasında grafik paketine ihtiyaç duyacaktır.

İkincisi grafik uygulaması yüzünden dikdörtgen sınıfında olabilecek herhangi bir değişiklik geometri hesap uygulamasınında yeniden derlenmesi , sınanması vb. gereksiz yükler getirecektir.

Nesne yönelimli dizayn içinde pek çok şekilde bu sorumluluklar birbirinden ayrılabilir.Ekli şekilde bir çözüm örneği sunulmuştur.

Paket Dizayn Prensipleri

Paket dizayn prensipleri sistemin yapılandırılmasında sistem mimarının göz önünde bulundurması gereken temel prensipleridir.Sınıf bazında izlenecek prensipler algılandıktan sonra bunların nasıl organize edileceği , nasıl kategorize edileceği vb. sorunlar bu prensipler yardımıyla çözülürler.

Paket Uyumluluk Prensipleri ( Package Cohesion Principles )

Bu prenipler sistem üzerinde yapılacak değişikliklerin en az etkiyi göstermesi için tasarlanmıştır.REP ve CRP prensipleri paketlere bağımlı olan kullanıcıların hayatını kolylaştırırken CCP prensibi daha çok değişiklik yapan geliştiricilerin hayatını kolaylaştırır.Bunu yanı sıra CCP paket içeriğini daha çok büyütürken CRP tam tersi bir işlev görür.Mimarinin ilk başlarında daha çok CCP uygulandığı görülürken ilerleyen safhalarda REP ve CRP prensipleri devreye girer.

Sürümün Yeniden Kullanım Eşitliği Prensibi ( The Release Reuse Equivalence Principle - REP)

Bu prensip bize yeniden kullanım için tasarlanan sınıfların her sürümde geriye doğru uyumlu olması gerektiğini söyler. Bir sınıf eğer yeniden kullanım için tasarlanmış ise doğal olarak pek çok kullananı vardır .Yeniden kullanım için tasarlanan sınıfların üzerinde yapılacak değişiklikler ; bağımlılıklardan dolayı pek çok başka sınıfı etkileyecektir.Dolayısıyla yeniden kullanılabilir olarak tasarlanan sınıflar doğru bir sürüm stratejisiyle geriye doğru uyum göstererek değişebilirler.Sık değişiklik gösteren sınıfların müşterileri bakım maliyetini karşılayamıyacaklarından kullanımdan vazgeçebilirler.

Sistem de tasarlanan sınıflar her biri bir pakete ait olmak zorundadır.Yeniden kullanım için tasarlanan sınıflarda bu kurala uymak zorundadır.Eğer bir sınıfa bağımlılık var ise aynı zamanda pakete de bağımlılık vardır.Dolayısıyla yeniden kullanılabilir olarak tasarlanan sınıfın bulunduğu paket ve paketin diğer içeriği de buna uygun tasarlanmalıdır.

Genel Toplanma Prensibi ( The Common Closure Principle - CCP)

Beraber değişen sınıflar aynı pakete konulmalıdır.Aksi takdirde paket bağımlılığından dolayı ilerleyen sürümlerde gereksiz sınama , derleme vb. yükler ortaya çıkar.Bu prensip aynı zamanda paketlerin bağımsız sınıflardan daha çok yeniden kullanım parçası olduğu fikrine dayanır.Eğer daha fazla paket değişiklik gösterirse yazılımın daha büyük parçaları bu değişiklikten etkilenecektir.Bu etkiyi minimal tutmak için en iyi çare beraber değişen sınıfların aynı pakette toplanmasıdır.

Genel Yeniden Kullanım Prensibi ( The Common Reuse Principle - CRP)

Beraber değişmeyen sınıflar aynı pakete konmamalıdır.Bir paket içinde bulunan sınıflar beraber kullanılıyorlar demektir.Bu her değişiklik ve yeni sürümde gereksiz olduğu halde değişmeyen sınıflarında yeniden gözden geçirilmesi , sınanması ve derlenmesi demektir.Bunun değişmeyen sınıflara bağımlı paketler üzerinde de aynı işlemlerin yapılması demek olduğu düşünülürse artan yük açıkça görülür.

Örneğin bu kurala uymayan işletim sistemlerinde ki değişiklikler sık sık başımızı ağrıtır.İşletim sisteminin yeni bir sürümü çıktığında biz değişikliğin tamamını istesek de istemesek de getirdiği yükü karşılamak zorunda kalırız.

Paket Eşleme Prensipleri (Package Coupling Principles )

Sonraki üç prensip paket eşleme prensipleri olarak anılırlar ve paketler arasındaki ilişkilerin nasıl kurulması gerektiği üzerinde dururlar.

Doğrusal Bağımlılık Prensibi ( The Acyclic Dependency Principle - ADP)

Bu prensipte, paketler arasındaki ilişki yapısında çevrimlerin bulunmamasıdır. Bir başka deyişle paketler arası ilişkiler tek yönlü ve doğrusal olmalıdır.

Şekildeki yapı oldukça modüler ve kendi içinde uyumlu olan bir mimaridir. Paketler arasındaki tüm ilişkiler tek yönlüdür.

Yukarıdaki şekilde görülen ”Comm Error” paketinde bir değişiklik yapıldığını varsayalım. Bu durumda “Protocol” “Comm” ve “GUI” paketleri dışında sistemin geri kalan kısmı bu değişiklikten etkilenmemiş olur. Ancak bir süre sonra uygulama da “Comm Error” paketinde çıkan hataların bir pencerede kullanıcıya gösterilmek istendiğini var sayalım.Bu değişiklik sonucu “Comm Error” paketinden sınıflar “GUI” paketinden ilgili sınıfları kullanarak bir pencere açıp hata mesajı versin.

Şekilde de görüldüğü gibi bu mimaride bir tasarım sorunu bulunmaktadır. Buna göre örneğin “Protokol” paketinde yapılacak bir değişiklik bağımlılıklardan dolayı “GUI”,”Comm”,”Modem Control” ve “Comm Error” paketlerini de etkileyecektir. Bu bir döngüdür ve istenmeyen bir durum oluşturur. Bu durum hem değişikliklerden masum paketlerin de etkilenmesine yol açacak hem de değişikliğin daha yavaş olmasına yol açacaktır.(Örneğin derleme performansı düşecektir , test süresi uzayacaktır vb)

Döngünün kırılması :

Bu şekilde oluşan döngüleri kırmak için 2 yol vardır:

1. Yeni bir paketin yaratılması. Bu durumda hem “GUI” paketinde bulunan “Comm Error” paketi için gerekli olan sınıflar ayrı bir pakete taşınmalıdır. Bu çözümün bir dezavantajı sistemde çok fazla paketin oluşabileceğidir.

2. Bağımlılığın çevrimi prensibini (DIP) uygulayarak da döngüler kırılabilir. Aşağıdaki şekilde ilk durum iki paket arasında oluşan bir döngüyü ve bu döngüye yol açan sınıfları göstermektedir. Kısaca Y sınıfı üzerinden B sınıfına olan bağımlılık kaldırılmış , bunun yerine B sınıfının Y sınıfı için gerekli parçaları bir “BY” arabirimine konarak , Y sınıfının bağımlılığı bu ara birime kaydırılmıştır. B sınıfı ise bu arabirimi geliştirmek zorunda olduğundan bağımlılık tersine dönmüştür.

Durağan Bağımlılıklar Prensibi ( The Stable Dependencies Principle - SDP)

Durağanlık yazılımda , değişiklik sıklığı ile ilgili bir kavramdır.Bir paket ne kadar az değişiklik görüyorsa o kadar durağandır demektir.Bu durağanlığı sağlıyan unsurlar içeriğin karmaşıklığı , büyüklüğü , sağlam yapılmış olması vb. sebepler olabilir .Ancak nesne yönelimli dizayn içerisinde paketin durağan olmasını gerektiren en önemli unsur pakete olan bağımlılık sayısıdır.Bir başka deyişle pakete ne kadar bağımlılık var ise paket o kadar durağan olmalıdır.

Yukarıdaki örnekte görülen X paketine diğer üç paketten bağımlılık vardır.X paketinde yapılacak her değişiklik diğer paketleri de etkileyecektir.Bu yüzden X paketi durağan olmak zorundadır.Bu bağımlılıklardan dolayı X paketi diğer paketlerden sorumlu olarak da anılır.Aynı zamanda X paketinin başka bir yere bağımlılığı olmadığı ve başka yerlerden etkilenmiyeceği için bağımsız olarak da adlandırılır.

Üstteki şekilde yer alan Y paketi bir önceki örneğin aksine durağan olmıyan bir görüntü sergilemektedir.Bu durumda Y paketi diğer paketlerden sorumlu olmıyan ve bağımlı olarak adlandırılır.

SDP prensibi bize tüm yazılımın durağan olması gerektiğini söylememektedir.Aksine nesne yönelimli dizayn oldukça esnek ve değişikliklere açık olmalıdır.Ancak bu prensipten anlamamız gereken sistem içinde bağımlılığın fazla olduğu paketleri durağan ilan etmemiz ve öyle olması içinde gayret sarfetmemiz gerektiğidir.Bu durum dizayn sırasında durağan paketlerin dikkatli seçilmesi ve iyi dizayn edilmesini gerektirir.Aynı zamanda geliştirme esnasında da bu paketlere öncelik verilmesi ve bağımlı paketlerin öncesinde geliştirmenin de değişiklik gerektirmiyecek şekilde tamamlanması gerekir.

Durağan Soyutluk Prensibi ( Stable Abstractions Principle - SAP)

Bu prensip bir önceki SDP prensibi ile yakın ilişkilidir.Kısaca durağan paketlerin soyut yapıda olmasını söyler.Bu prensibi OCP ve DIP prensiplerinin paket boyutunda uygulanması olarak adlandırabiliriz.

Yukarıdaki örnekte durağan bir paketin içeriğinin soyut yapılarak prensibin uygulanışı gösterilmiştir.Durağan paketin gerçekleştirimi bir başka pakette yapılarak dizayn esnek bir hale getirilmiştir.

Diğer Dizayn Prensipleri

Kapsülleme Prensibi ( The Encapsulation Principle - EP )

Nesne yönelimli yazılımda kapsulleme prensibi sınıfların dışarıya gereği kadar bilgi sunmasını , iç yapılarını dışarıya yansıtmamalarını söyler.Bu prensibin paketlere yansıtılmış hali bir paketin içindeki detayların dışa kapalı kalmasıdır. Buna göre bir paketin içindeki sınıflar ne kadar dışarıya kapalı ise kapsulleme o kadar fazladır.Bu prensibe göre paketin iç yapısının dışında dış kullanımda gerekli olmıyacak sınıflar dışarıya kapalı tutulmalıdır.

Sınırlı Boyut Prensibi ( The Limited Size Principle - LSP)

Bu prensibe göre bir paketin içindeki alt paket ve üst seviye sınıf sayısı belli bir boyutu aşmamalıdır. Üst seviye sınıf kavramı yazılım içinde mimari açıdan önemli sayılan sınıfları ifade eder.Bir sınıfa uygulama içinden bağımlılık ne kadar fazla ise o sınıfın önem derecesi o kadar artacaktır.

Paketlerin boyunun gereğinden fazla tutulması paketin sorumluluğunun artmasına ve bakımının gittikçe zorlaşmasına yol açacaktır.Paket üzerinde yapılan değişiklikler de buna paralel daha çok yeri etkileyecektir.İyi projelerde paket içeriğindeki alt paket ya da üst seviye sınıf sayısının 10-15 ‘i aşmamasına özen göstermek gerekir.

Kaynakça

Booch, G., Object Oriented Design with Applications, Redwood City, CA: Benjamin/Cummings, 1991.

Robert C. Martin ,”Design Principles and Design Patterns” , Object Mentor Inc.

Samudra Gupta , “Fine Tuning Abstraction” , http://javaboutique.internet.com

James Rumbaugh , “Object Oriented Modelling and Design “ , Prentice Hall-1991

Chidamber, S. R. & Kemerer, C. F., “A Metrics Suite for Object Oriented Design”, IEEE Transactions on Software Engineering, Vol. 20, #6, June 1994.

Martin Fowler , “Refactoring :Improving the design of existing code” , 1999

Yazılım Mimarisi (Software Arhitecture)

2011-04-22T15:37:00.000+03:00

Yazılım geliştirme sürecinin ilk adımlarında problem analizi yapılarak sistemde nelerin yapılması gerektiği ortaya konur. İhtiyaçların nasıl karşılanacağı , nasıl çözümler geliştirileceği ise dizayn disiplinin konusudur. Dizayn geliştirme boyunca çözümler için alınan kararlar öncelikle üst seviyede alınır ve giderek detaylandırılır.

Yazılım mimarisi ; dizayn disiplininin ilk aşamalarında ortaya çıkar.Yazılım Mimarisi deneyimli yazılımcılar tarafından kolaylıkla anlaşılabilse de , tarifi oldukça zor bir kavramdır.Yazılım dizaynı ile yazılım mimarisi sıklıkla birbirine karıştırılmaktadır.Dizayn sistemin tüm ayrıntılarını içerdiği halde mimari bize sistemin ne olduğunu hakkında bilgi verir.Başka bir deyişle mimari ; dizaynın belli özellikleri öne çıkarılmış bir alt kümesidir.

Ancak bu tanımdan mimarinin , dizayndan sonra hazırlandığı gibi bir sonuca ulaşılmamalıdır.Aksine mimari öncelikle hazırlanan bir kavramdır.Dizayn daha sonra mimaride belirtilen parçaların detaylandırılmasını kapsar.

Yazılım Mimarisi “ sistemi tanımlayan en üst seviye kavramlar” olarak nitelendirilebilir.

Yazılım mimarisi şunları içerir :

Sistemin organizasyonu hakkında önemli kararlar
Sistemin önemli yapısal elementleri ve bunların arayüzleri ile birbirleri arasındaki etkileşim
Sistemin önemli yapısal ve davranışal elemanlarının altsistem’lere dağılımı

Yazılım mimarisi yapı ve davranışların yanı sıra kullanılabilirlik , fonksiyonalite , performans , esnekllik , yeniden kullanım , anlaşılırlık , ekonomik ve teknolojik kısıtlar gibi özellikleri de yansıtır.

Tüm bu özellikleri ile “Yazılım Mimarisi” sistemin anayasasıdır.Tüm yazılım geliştirme sürecinin merkezinde durur ve her türlü faliyete kılavuzluk eder.

Yazılım mimarisi pek çok sebepten dolayı önemlidir :

Sistemin karmaşıklığını yönetmek ve bütünlüğünü korumak için , kontrol edilebilir bir yapı sunar

Karmaşık sistemler kendini oluşturan parçaların bütününden daha fazla şey ifade ederler.Böyle sistemler kendini oluşturan parçaların nasıl bir araya geldiğini ve çalıştıklarını düzenledikleri gibi , gerektiğinde sistemin nasıl büyüyeceğini de tariflemelidir.Mimarisi tarif edilmemiş sistemde yapılacak her türlü değişiklik tam bir kaos olacaktır.Mimari ortak bir referans ve sözlük sunarak sistemin anlaşılırlığını ve iletişimi iyileştirir.

Bundan başka mimari tüm ana parçaları belirlediğinden bundan sonraki tüm çalışmalar için bir adresleme sağlar.Hangi parçanın nerede ele alınacağı , hangi kavramın nereye oturtulacağı mimari ile belirlenir.Tüm parçaların görevleri ve kapsamı belirlendiğinden kaos ortadan kalkar.

Yeniden kullanımı arttıran kullanışlı bir yapı sunar

Sistem bileşenlerinin ve bunların arabirimlerinin mimaride tariflenmesi ; bileşenlerin hem sistem içinde hem de başka sistemler içerisinde yeniden kullanımını önemli ölçüde arttırır.Sistem içinde ortak bileşenlerin adresleri belirlendiğinden kullanımları artar .Örneğin aynı çözümün sistem içerisinde birden fazla geliştirilmesi gibi problemlerin önüne geçilmiş olur.Dış sistemler de (örneğin geliştirilen diğer projeler ) ise kendi çözümleri içerisinde bu bileşenleri kullanabilirler.

Daha geniş ölçekte mimarinin kendisi de farklı çözümlerde yeniden kullanım olanağı bulabilecektir.

Proje yönetimi için temel teşkil eder

Projenin planlama ve kaynak yönetimi organizasyonu ana bileşenler etrafında oluşturulurlar.Temel yapısal kararlar mimari takımı tarafından bütünlük içerisinde yaratılırlar.Geliştirme aktiviteleri küçük takımlar halinde bileşenler etrafında yapılırlar.

Yazılım geliştirme süreci oldukça karmaşık ve zor bir süreçtir.Bu süreçte dağılmamanızı sağlıyacak şey , sürecin merkezinde duran şey yazılımınızın mimarisi olmalıdır..

Altsistemler (Subsystems)

Bileşen sistem içerisinde bulunan , iyi tanımlanmış arabirim ve davranışlarıyla içeriği hakkında güçlü bir kapsulleme sunan , aynı zamanda değiştirilebilir , kaynak ya da çalışabilir durumda ki bir gurup koda verilen isimdir.

Sistem dizaynının ilk adımı sistemin ana bileşenlerinin tariflenmesidir.Bu ana bileşenler aynı zamanda altsistem olarak da adlandırılırlar.Altsistemler bir sınıf ya da fonksiyon değildirler.Altsistemler sınıflar , ilişkiler , operasyonlar , olaylar , kurallar gibi birbiriyle ilişkili pek çok kavramı barındıran paketlerdir.Altsistemler genellikle sundukları servis ile tanımlanırlar.Servis ortak bir amaca hizmet eden bir gurup fonksiyon olarak tanımlanabilir.Örneğin işletim sistemleri bünyelerinde bellek yönetimi , dosya yönetimi gibi alt sistemler bulundururlar.

Her altsistem ; sistemin geri kalanı için bir arabirim sunar.Arabirim ; altsistemin tüm fonksiyonalitesini dışarıya sunar ve altsistemin fonksiyonalitesini belirler.Ancak işlemlerin altsistem içersinde nasıl gerçekleştiğini göstermez.Altsistemler sistemin geri kalanını etkilemeden bağımsız olarak dizayn edilebilirler.

Bir sistem sınırlı sayıda alt sisteme sahip olmalıdır.Örneğin 20 muhtemelen çok sayıda altsistemi işaret etmektedir.Altsistemler de kendi içlerinde altsistemlere ayrılabilirler. Altsistemlerin diğer altsistemlere olan bağımlılıkları mümkün olduğunca kısıtlı tutulmalıdır.Bağımlılıklar tercihan aynı seviyedeki altsistemler yerine barındırdığı altsistemler ile arasıda kurulmalıdır.En alt seviyedeki alt sistemlere modül adı verilmektedir.

İki altsistem arasında kurulacak ilişkiler iki şekilde sınıflandırılmaktadır:

İstemci – Destekçi (client-supplier) : Bu tür ilişkide istemci , destekçi’nin arabirimini bilmek zorundadır.Bu arabirim üzerinden istediği servisleri alır.Ancak bu tür bir ilişkide destekçi ; istemci hakkında bir bilgiye sahip olmak zorunda değildir.Tek taraflı bir bağımlılık söz konusudur.
Eşdüzeyli (peer-to-peer) : Bu tür bir ilişkide altsistemler birbirlerini kullanırlar.Bu tür ilişkiler daha karmaşıktır.Her iki altsistem de birbirinin arabirimini bilmek zorundadır.İletişimin dizaynı oldukça karmaşık ve hataya açıktır.

Altsistemler arasında ilişkiler kurulurken mümkün mertebe istemci-destekçi tarzı ilişkiler kurulmaya çalışılmalıdır. Sistemin altsistemlere açılımı yatay olarak katmanlar , dikey olarak bölümler olarak organize edilebilir.

Katmanlar (Layers)

Katmanlar , sistem içersinde birbiri ardına gelen sanal dünyalar olarak nitelendirilebilir.En üst seviye katmanlar uygulamaya has fonksiyonalite sunarken , alt seviyeler daha çok çalışma ortamına özel bileşenleri içerirler.Genel amaçlı servisler ve iş mantığı servisleri ise genellikle orta seviyeler yer alır. Katmanlar içerisinde birbiriyle benzeşen nesneler olabilir.

Katmanlar arasında bilgi tek yönlüdür.Her katman daha alt seviyede ki katmanlar hakkında bilgi sahibi olabilir ancak üst seviyeler hakkında bir bilgisi yoktur.Alt katmanlar ile üst katmanlar arasında istemci-destekçi tarzı ilişki söz konusudur.

Katmanlanmış Mimariler’de açık ve kapalı olmak üzere iki form söz konusu olabilir.Kapalı mimaride katmanlar sadece takip eden katmanla iletişim kurabilir.Bu katmanlar arasında bağımlılıkları azaltır ve değişiklikler için daha esnek bir sistem sağlar.Çünki katman’ın arabirimleri üzerinde yapılacak değişiklik sadece bir katmanı etkiler.Açık mimaride katman ; alt seviyelerin tümüne erişebilir .Bu operasyonların her seviyede yeniden tanımlanma gereksinimini ortadan kaldırır ve daha verimli ; küçük kodlar sağlar.Ancak değişiklikler pek çok seviyeyi etkileyebilir.Bu yüzden açık mimari , kapalı mimariye göre daha az güvenli bir yapı sunar.

Katmanların yalnızca en alt ve en üst seviyeleri problem durumuna göre belirlenir.En üst seviye talep edilen seviyedir , en alt seviye ise kaynakları (database , donanım , işletim sistemi vb) yönetir.

Katmanların sayısı ve komposizyonu hem problemin hem çözümün karmaşıklığına bağlı olarak değişebilir.

Bölümler (Partititons)

Bölümler sistemi dikey olarak bölen , her biri bir çeşit servis sunan , bağımsız ya da zayıf eşlemeli alt sistemlerdir.Örneğin bir işletim sisteminde dosyalama sistemi , sanal bellek kontrolü , aygıt kontrolü gibi bölümler bulunur.Bölümler birbirleri hakkında büyük bağımlılıklar yaratmayacak kadar bilgi sahibi olabilirler.

Bir sistem çeşitli kombinasyonlarda hem katmanlara hem de bölümlere parçalanabilir.Katmanlar bölümlere ayrılabilir ya da bölümler katmanlara ayrılabilir.

Bileşenler (Components)

Bileşenler sistem içerisinde modul , paket ya da altsistem gibi kesin sınırları olan ve sorumluluğu belirlenmiş elemanlar olarak da tanımlanabilir.Bileşenler sisteme entegre olabilir ve değiştirebilir yapılardır.Bu aynı zamanda bileşenlerin başka sistemler içerisine de entegre edilebilir ve yeniden kullanılabilir olduğunu anlatır.

Moduler bir mimaride bileşenleri bağımsız olarak tanımlar , izole eder , dizayn eder ve geliştirebilirsiniz edebilirsiniz.Daha sonra bileşenler yine bağımsız olarak test edilip sisteme entegre edilebilirler. Bu bileşenlerden bir kısmı genel çözümler sundukları tesbit edilirse daha geniş alanlarda kullanılabilirler.Bu yeniden kullanılabilir bileşenler organizasyonun genel yazılım verimliliğini ve kalitesini arttırmanın bir yoludur.

Corba , Active X , Java Bean gibi bileşen altyapıları tüm endüstriye yeniden kullanılabilir bileşenler geliştirmenin yolunu açmıştır.Bu sayede çözümünü beğendiğimiz bileşenleri alıp sistemlerimize entegre edebilmekteyiz.

Çalışma Alanı (Domain) Kavramı

Sistemimizi yapısal olarak katmanlara ve bölümlere ayırabiliyoruz.Bir üçüncü boyut olarak gelen çalışma alanı (domain ) aslında sistem içerisinde adreslenen çözümlerin genelden özele doğru yeniden kullanılabilir parçalar halinde düzenlenmesidir diyebiliriz.Örneğin muhasebe alt sisteminin genel , hazırlanan alana özgü (sigorta , bankacılık vb) ve şirkete özgü parçaları.Çalışma alanlarından katmanlar ve bölümler gibi yapısal bir parçalanma değil mantıksal bir parçalanma olarak söz edebiliriz.

Örnek şekil bir uygulama parçalarının nasıl ele alındığını ve içindeki çalışma alanlarının nasıl tesbit edildiğini göstermektedir.Buna göre uygulama içerisindeki iş mantığı içermeyen yeniden kullanılabilir kodlar framework içerisinde toplanmış , işe özel ancak o iş içinde yeniden kullanılabilir kodlar bir başka parçya ayrıldıktan sonra geriye kalan kodlar uygulamaya özel olarak belirlenmiştir.

Çalışma alanlarının tesbiti sistemdeki genellemelerin ve farklılıkların tesbitini gerektirir.Sistemin daha genel kullanım bulabilecek fonsiyonaliteleri genelden özele doğru parçalara ayrılmalıdır.Bunun en iyi etkisi yeni sistemlerin dizaynı sırasında , üzerinde özelleştirmelerin yapılabileceği sistemlerin hazır halde oluşmuş olmasıdır.

Çalışma alanı tesbitine problem analizi sırasında başlanmalıdır ve problem bağlamında önceden hazırlanmış çözümler değerlendirilmelidir.Aksi takdirde hazır yapıların değerlendirilememesi ve gereksiz iş gücü kaybının yanı sıra hazırlanacak çözümlerinde yeniden kullanılamaması gibi sakıncalar oluşacaktır.Alttaki şekil uygulama süreçleri ile çalışma alanlarının oluşturulma süreçleri arasındaki ilişkiyi göstermektedir.

Yazılım mühendisliğini istekler doğrultusunda geliştirilen , tek sisteme yönelik bir çalışma olduğunu varsayarsak , çalışma alanı mühendisliği pek çok sisteme uyabilecek yeniden kullanılabilir çözümler sunan bir çalışmadır denilebilir.

Çalışmalar yapılırken hazırlanan çözümlerin daha geniş alanlara uygulanabilip uygulanamıyacağı sorgulanmalı ve ilerideki projeler için yeniden kullanılabilir çözümler hazırlanmalıdır.Bu işlem bizi yavaşlatır görünse de tüm süreçler içindeki avantajı ve sağlıyacağı katkılar inanılmaz boyutlarda olabilir. Alan çalışmaları sonucu elimizde yeniden kullanılabilir kod parçalarının yanı sıra çözüm tasarımları da oluşacaktır.Bu tasarımlar farklı dillerde ve ortamlarda yeniden uyarlanabilir olduğu göz önüne alınırsa , kurumsal bir yapı oluşturulmuş ve farklı çözümler geliştiren firmalara olabilecek katkısı daha iyi anlaşılır.

Alan çalışmalarına sürecin en başından başlanamasa bile hazır sistemler üzerinde çalışma alanı analizleri yapılarak yeniden kullanılabilir parçaların tesbiti mümkündür.

İlişkisel Veri Tabanı Dizaynı

2011-04-22T11:41:00.009+03:00

      Çalıştığım kurumlarda işe alım görüşmelerinde çoğu kez değerlendirme kurullarında yer aldım. Yeni mezun adayları değerlendirmek için başvurduğum yöntemlerden biri yazılım sürecini nasıl algıladıklarını değerlendirmektir. Konu kurumsal yazılımlar olunca, yazılım yaşam döngünüzde en önemli faktörlerden biri,doğal olarak veri modelinizi nasıl oluşturduğunuzdur. Sonuçta kurumsal yazılımınızın hayatı sona erdiğinde ve emekliye ayrılması gündeme geldiğinde dahi ortada kalacak tek şey oluşmuş verilerdir. Hal böyleyken katıldığım görüşmelerde bana veri modelini oluştururken nelere dikkat ettiğini anlatabilen aday sayısı dramatik bir şekilde az. Bunu kendimce çeşitli sebeplere bağlamakla beraber, durumun piyasa olan etkisinden de biraz bahsetmek isterim. Özellikle danışmanlığa başladığım günden beri farklı veri modelleri ile karşılaştım. Yüzlerce kolondan oluşan, normalizasyondan son derece uzak, OLTP için hazırlanmış veri modelleri beni ilk başlarda korkuttuysa da, durumun son derece yaygın olduğunu sonradan anladım. Nacizhane bir tavsiye olarak özellikle IT yöneticilerine, OLTP sistemlerinde için kavrayamadıkları veri tabanı modelleri, kolonlarının sonunu göremedikleri tablolar ile karşılaşıyorlar ise acil tedbirlere başvurmalarını öneririm.

   Aşağıdaki yazıyı Internet üzerinden erişilebilir kaynaklara bir yenisini daha eklemek ve belki de bu yolla bir kişiye olsun faydasının dokunmasını umarak burada yayınlıyorum. Bu yazının konusu özellikle veri tabanı dizaynı sırasında kavramsal ve mantıksal modelin hazırlanmasıdır. Diğer bazı konulara bilgi vermek ve konunun bütünlüğü açısından , kısaca değinilmiştir.

Esen Kalın

VERİ TABANI SİSTEMLERİNİN ORTAYA ÇIKIŞI

         Veri tabanı yönetim sistemlerin ortaya çıkışından önce kullanılan klasik dosya sistemlerinde , veri kümeleri fiziksel olarak ayrı ayrı dosyalara saklanmaktaydı.Kavramsal düzeyde bu dosyalar arasında bir ilişki kurulabilmesine rağmen , bu ilişkilerin kontrolünün veri dosyalarını kullanacak her programa ayrı ayrı uygulanması gerekliydi.Bu da dosyaları kullanacak her programın veri bütünlüğünü ve doğruluğunu bozmaması gerektiği anlamına gelmekteydi.

Benzer şekilde aynı anda birden çok dosyayla çalışan programların dosyaları yönetiş biçimi olduça güçtü.Sözgelimi programınızın başında kullanıcağınız bütün dosyaları açmak , sonunda da doğru bir şekilde kapamak zorundaydınız.

Bütün bunlar programların yazımını oldukça güç kılıyor ve sıklıkla hatalar yaşanabiliyordu.Yaşanan bu ve bunun gibi sıkıntılar yüzünden programlar ile veri arasındaki bu sıkı ilişkiyi biraz soyutlamak gereği ortaya çıktı.Bu sıkıntıları çözmek içinde veri tabanı sistemleri doğdu.

Veri tabanları ayrı ayrı bulunan dosyaları kendi havuzu içersinde toplandı.Programlar tek tek dosyalar yerine artık veri tabanına bağlanıp isteklerini veri tabanı üzerinden karşıladılar.Programlarla veri tabanının konuşması için özel bir dil geliştirildi.(SQL)

Veri tabanı, kısaca tanımını yapmak gerekirse, uygulama sistemlerince kullanılmak üzere belirli ortamlara saklanmış birbirleriyle ilişkili veriler topluluğudur.Tabi veri tabanının üzerinde havuzdaki verilerin yönetimiyle sorumlu bir veri tabanı yönetim sistemi bulunur.(Database management system) .Bu iki kavram sıklıkla beraber anılırlar.

Veri tabanı yönetim sisteminin temel görevlerine gözatıcak olursak :
• Security (Güvenlik)
Kullanıcı yönetimi , veri tabanına bağlanmak isteyen kullanıcının tanımlanmış haklarına uygun şekilde davranmasını sağlamak vs
• Integrity (Bütünlük /Doğruluk)
Verilerin beklenmeyen durumlarda bozulması , yanlış veri girişinin önlenmesi , beklenmeyen durumlarda verinin tamiri , kaynak paylaşımının düzenlenmesi (veri üzerinde aynı anda birden fazla değişiklik yapılmasını önlemek) gibi
• Time Sharing (Zaman paylaşımı)
Veri tabanını üzerinden yapılan işlemlere belli zaman aralıklarıyla cevap verilmesi , kullanıcılara işlemci zamanının paylaştırılması vs.

VERİ TABANI SİSTEMLERİNİN SINIFLANDIRILMASI

Veri tabanı konusunda genel bir bilgilendirmeden sonra veri tabanları üzerinde verinin nasıl saklandığına gelmek gerekir.Veri tabanları veriyi saklama biçimlerine göre çeşitli katagorilere ayrılırlar. Bunlardan bazıları:

1- Hierarchical (Hiyerarşik )
2-Multidimensional (Çokboyutlu )
3-Relational (İlişkisel)

Hierarchical (Hiyerarşik )
Bu modelde veriler ağaç yapısında dururlar.Bir parent-chield iişkisi vardır.Aşağıda yayımcı – yazar – kitap ilişkisinin hiyerarşik modelde nasıl gösterildiği örneklenmiştir.
Hiyerarşik modelde ebeveyn’in girişi yapılmadan çocukların girişi yapılamaz.Eğer bir ebeveyn silinmek zorunda kalınırsa ilgili tüm çocuklar da silinir.
Ağ modeli (network model) hiyerarşik modelin geliştirilmiş halidir. 1960’ların sonunda hiyerarşik modelde bazı iyileştirmeler öngörülerek hazırlanmıştır.

Multidimensional (Çokboyutlu )
Datawarehouse ve OLAP gibi uygulamalar multidimensional modeli populer hale getirmiştir.Multidimensional modelde temel veri yapısı array (dizin)’dir.Genelliklede data iki boyutlu arrayler (matrix) halinde durur.Temel gaye analiz için gerekli veriye hızlı ve kolay bir şekilde erişmektir.

Multidimensional modelde iki boyut’dan daha fazla boyut’da olabilir.Bu modelde veri sorgulanmak için pek çok kolaylık sunmasına rağmen , verinin kaydı oldukça zordur.

Relational (İlişkisel)

Relational model (ilişkisel model) 1970’lerin başında E. F. Codd tarafından önerilmiştir.İlişkisel data modeli ticari veri tabanı yönetim sistemlerinin temel taşı durumundadır.Bu modelde veriler tablolar halinde durur.Her tablo kolonlar ve satırlardan oluşur.Kolonlar tablonun tanımlanması sırasında belirlenirler , satırlar ise tablo içersine girişi yapılan verileri belirtir.

İlişkisel model bundan sonra da bu yazı da üzerinde durulacak modeldir.

VERİ TABANI DİZAYNI

Bir veri tabanının inşası sırasında en önemli adım veri modelinin hazırlanmasıdır.Gerekli veri tabanı yönetim sisteminin seçilmesi , kurulması , fiziksel kaynaların atanması gibi işlemler işin en kolay yanıdır.Çok para verip Oracle veri tabanı yönetim sistemi almanız mükemmel bir veri tabanına sahip olduğunuz anlamına gelmez. Veri tabanınızda verilerin nasıl duracağını , veriler arasındaki ilişkileri , özeliklleri vs. belirlemek oldukça kapsamlı bir iştir.Veri tabanının oluşturulması için gerekli adımları sıralıyacak olursak :

1. İhtiyaç Analizi
2. Kavramsal modelinin hazırlanması
3. Mantıksal modelin hazırlanması
4. Fiziksel modelin hazırlanması
5. Modelin uyarlanması

şeklinde sayabiliriz.

Bu yazının konusu kavramsal ve mantıksal modelin hazırlanmasıdır.Diğer konulara sadece bilgi vermek açısından , kısaca değinilecektir.

İhtiyaç Analizi
    İş ihtiyaçlarının belirlenmesi ve neyin hazırlanacağının belirlenmesidir diyebiliriz.Tüm gereksinimler iyice anlaşılmadan ve üzerinde iyice tartışılmadan hazırlanan bir veri tabanı , eğer çok basit değilse mutlaka pek çok eksik içerecektir.

İhtiyaçların sağlıklı bir şekilde ortaya dökülmesi için kabaca şu adımlardan geçilir:

1. Gerekli kaynaklardan bilginin toplanması
2. İstenen sistemin uygun bir modelleme tekniği ile modellenmesi
3. Model üzerinde tarafların uzlaşma sağlanması

İyi hazırlanmış bir model ile tam olarak ne yapıldığını ve ne yapılmak istendiğini gösterebilir ve anlayabilirsiniz. İhtiyaç analizi sayesinde sistemde oluşacak tüm fonksiyonları, sistemde yer alan nesneleri ve ilişkilerini görebilirsiniz.

KAVRAMSAL MODELİN HAZIRLANMASI

Kavramsal model aslında nesne-ilişki gösteriminin (entity-relationship diagram ) hazırlanmasıdır diyebiliriz.Bu model genel database modelinden bağımsızdır.Örneğin bu modelde primary key , foreign key , index gibi şeyler bulunmaz.Ve ilerde bahsedilecek olan normalizasyon henüz bu modelde yapılmamıştır. Bu noktada bazı terimleri vermek yerinde olucaktır.

Nesne (Entity) : Var olan ve birbirinden ayrılabilen herşeye nesne denir.Örneğin ağaç , kuş , uçak , müşteri , çalışan vs. Nesne genel bir kavram olup aslında bir kümeyi belirler.Örneğin Uçak bir nesne tanımı THY’nin 1001 nolu Boeign tipi yolcu uçağı ise o kümenin içindeki bir üyedir (instance) .

Nitelik (Attribute) : Var olan her nesne diğerinden nitelikleriyle ayrılabilir.Örneğin bir müşteri nesnesini ele alıcak olursak adı , müşteri numarası gibi bilgiler nesnenin niteliklerini oluşturur.

Anahtar (Key) : Anahtar bir nesne içinde bir üyeyi diğerinden ayırmaya yarayan bir ya da birden fazla niteliğin adlandırılmasıdır.

İlişki (Relation) : İlişki bir nesne ile diğeri arasındaki bağlantının , etkileşim ya da ortaklığın tanımlanmasıdır.Örneğin “personeller belli departmanlara bağlı olarak çalışırlar” kuralı personel nesnesi ile departman nesnesi arasında bir ilişkidir.

Nesne-ilişki diyagramı (Entity Relationship diagram) : Kısaca nesneler ve ilişkilerini gösteren grafiksel bir sunum şeklidir.Kısaca ERD diye de anılır.

Nesne ve Niteliklerinin Tanımlanması

Kavramsal modelin hazırlanmasının ilk aşaması nesnelerin tanımlanmasıdır.Nesne bir kişi , yer , düşünce , aktivite veya işi ilgilendiren olaylar olabilir.Nesneler tanımlanırken önceden hazırlanan sistem modelinden , görüşmelerden veya raporlardan yararlanılabilir.Nesneler elde edildikten sonra nitelikleri tanımlanır.Bir nitelik şu değerleri alabilir

-Serbest bir değer
-Null değer (hiçbirşey)
-Bir değer gurubu içinden bir değer
-Türetilmiş değer

      Null değerin iki anlamı vardır.Ya o nesne örneği için alacağı değer bilinmiyordur ya da o örnek o nitelik için herhangi bir değere sahip değildir.Örneğin müşteri bilgilerinde tutulan kızlık soyadı erkek müşteriler için hiçbir anlam ifade etmez , yoktur.Erken müşteriler için bu nitelik NULL değerini alır.
Bazen tanımlanan iş kuralları ya da doğal kurallar sonucu nitelikler belli bir değer gurubu içinde kalmak durumunda kalırlar.Örneğin cinsiyet niteliği sadece erkek ya da kadın olarak seçilebilir ya da il kodu türkiye için sadece 1 ile 81 arasındaki tamsayılar olabilir gibi.Bu gibi doğal ya da sanal değer gurupları belli bir nitelik alanı (attribute domain) oluştururlar.

   Türetilmiş değer diğer niteliklerin işlenmesiyle oluşan bir değerdir.( ortalama değer ya da toplam gibi.)
Kavramsal modelde bu noktadan sonraki adım anahtarların belirlenmesi olucaktır.

Anahtarların Belirlenmesi

   Anahtar bir nesne içinde üyelerin diğerinden ayrılmasını ve o üyenin tanımlanması sağlayan nitelik ya da niteliklerdir.

    Elimizde bir müşteri nesnesi olduğunu düşünelim ve isim , telefon numarası , adres niteliklerine sahip olduğunu varsayalım.Eğer her müşteri ayrı bir telefon numarasına sahipse telefon numarası key olabilir ya da her müşterinin adı diğerinden değişikse müşteri adı da anahtar olabilir.

Mantıksal düzeyde sadece potensiyel ana anahtarların (primary key ) belirlenmesi yeterlidir.Bunlar aday anahtar (candidate keys) olarak adlandırılırlar.

     Belirlenen aday anahtarları oluşturan nitelikler mutlaka bir değer taşımak zorundadır.Başka bir deyişle NULL değer alamazlar.Bunun dışında aday anahtarlar nesne üyeleri arasında her üye için farklı bir değer almak zorunda , yani bir anahtar yalnız bir üyeyi tanımlamaladır.Örneğin aynı telefona sahip iki müşteri varsa telefon numarası bir anahtar olarak tanımlanamaz .
      Bazen bir nitelik ile bir anahtar elde edilemeyen durumlarda birden fazla nitelik bir araya gelerek bir anahtar da oluşturabilir.Buna bileşik anahtar (composite key) denir.

    Bazen hiçbir niteliğin üyeleri ayırdetmeye yaramadığı durumlarda yapay anahtar (artifical key) ‘e ihtiyaç duyabilirsiniz.Örneğin örneğini verdiğimiz müşteri nesnesi için müşteri numarası diye yapay bir nitelik oluşturup anahtar olarak tanımlayabilirsiniz.

Nesne ve Niteliklerin Gösterimi

Nesne ve niteliklerin grafiksel gösterimi bu aşamadan itibaren dizayn çalışmalarında oldukça yardımcı olucağından diyagram oluşturmaya başlamakta büyük fayda vardır.Aşağıdaki şekilde üç nesnenin yer aldığı bir diyagram gösterilmiştir.Altı çizili nitelikler anahtar alanlardır.

İş Kurallarının Gösterilmesi

Veri tabanları aslında sadece verinin saklanması değil aynı zamanda bir takım iş kurallarının saklanması ve uygulanması görevini de sürdürürler.Bu yüzden veri modeli çıkartılırken bir takım iş kuralları da modelde yer alır.
İş kuralları kavramsal modelde çeşitli şekillerde yer alırlar.
Nitelikler üstünde nitelik aralıkları (ranges) bir niteliğin alabileceği değer alanını belirler . Yine nitelikler üzerinde kısıtlamalar (constraints ) yani diğer bir niteliğe göre durumunu tanılayabilirsiniz.Bitiş tarihinin , başlangıç tarihinden büyük olması gibi.
Derlenmiş veriler (Derived Dat) üzerinde zaten doğal olarak bir takım iş kuralları yer almaktadır.Derlenmiş veriler diğer niteliklerin verilerinin işlenmesiyle oluşur.Örneğin toplam yada ortalama değerler gibi.
İlişkiler (Relationships) de iş kurallarının modele yansıtılmasının bir diğer yoludur.İlişkiler adı üzerinde nesneler arasındaki ilişkileri tanımlar.Bu sayede örneğin kitap nesnesinde tanımlanmamış bir kitabın , kitap satış listesinde yer almaması gibi bir kuralı tanımlayabilirsiniz.Bundan sonraki bölüm bu konu üzerinde duracaktır.

Nesneler Arası İlişkiler (Relationships between entities)

İlişkişkiler bize nesnelerin diğerleriyle nasıl çalıştığını gösterir.Nesneler arasında çok çeşitli ilişki tipleri olarbilir.Anlamak için örneklendirecek olursak:

• Bağımlılık(Dependence) Bir nesnenin varolması bir diğerinin varolmasına bağlıdır ve kendi başına tam bir anlam ifade etmez.Örneğin müşteri telefonu nesnesi müşteri tanımlanmamışsa bir anlam ifade etmez.
• Düzenleme(Composition) Bir nesne diğerini düzenler.Örneğin araç nesnesi şasi , motor ,gövde nesneleri ile düzenlenir.
• Ürün(Production) Bir nesne diğerini üretir yaratır yada üretir.Örneğin kitap nesnesinin olabilmesi için onu üretecek bir yazar nesnesine ihtiyaç vardır.
• Üyelik(Membership) Bir nesne kendinden daha büyük bir sınıfın üyesidir.Örneğin çalışan nesnesi departman nesnesinin bir üyesidir.
• Kullanma(Use) Bazen bir nesne diğer bir nesne yi kullanır yada onun özelliklerine ihtiyaç duyar.Örneğin proje nesnesi , çalışan nesnesini kullanır.

Peki ilişkilerin mantıksal model içindeki özellikleri nelerdir.Bunu tanımlamak için bir örnek üzerinden gidelim.Örneğin personel ve departman nesnelerini ele alalım.Bu iki nesne arasındaki ilişki “personel bir departmana bağlı olarak çalışır “ şeklindedir.Bu ilişkinin özelliğini belirlemek için iki soru gereklidir :

“Bir departmanın kaç çalışanı olabilir ? “
“Bir personel kaç departmanda çalışabilir ?”

• Eğer her iki soruya da bir cevabı verilmişse bu birebir (1-1) bir ilişkiyi tanımlar.Örneğin bir departmanın bir personeli olabilir ve bir çalışan bir deparmanda çalışabilir
• Eğer iki sorundan birine bir diğerine birden fazla bir değer söylenmişse bu bire –çoklu ilişkiyi gösterir (1-m).Örneğin bir departmanda birden fazla personel çalışır fakat bir personel yalnız bir departmanda çalışabilir.
• Eğer her iki soruyada birden büyük bir değerle cevap verilmişse bu çoklu-çoklu (m-m) ilişkiyi gösterir.Örneğin bir departmanda birden fazla personel çalışabilir ve bir personel birden fazla departmanda çalışabilir durumu

İlişkinin iki tarafına bakıcak olursak her bir nesne için ilişki sadece iki durum alabilir.Birli ya da çoklu .İlişki tanımlanırken , tüm seçenekler sadece yukardaki kadar değildir.Örneğin bir personel departmana bağlı olarak ya da bağımsız olarak çalışabilir gibi bir durum da söz konusu olabilir.İlişkinin nesne açısından birli yada çoklu olmasına göre seçenekleri de şöyle sıralayabiliriz.

• Kesinlikle bir (Exactly one) Birli ilişkide ilişkinin mutlaka kurulması durumudur.(personel kesinlikle bir departmana bağlı olmalıdır)
• En çok bir (At most one) Birli ilişkide mutlaka bir bağımlılık aranmaması durumudur.(Bir personel bir departmana bağlı yada bağımsız olarak çalışabilir)
• En az bir (At least one) Çoklu ilişkide mutlaka bir ilişki kurulması durumudur.(Bir departman kurulması için mutlaka en az bir personel gereklidir.)
• Herhangi bir sayıda (Any Number) Çoklu ilişkide mutlaka ilişkinin aranmaması durumudur.(Bir departman kurulması için mutlaka yer alıcak eleman gerekmez)

İlişki türleri ve seçeneklerini açıkladığımıza göre bunların nesne ilişki diyagramında (ERD) nasıl gösterildiğine geçebiliriz.

Bu noktada kullanacağınız araç ve modelleme tipine göre modelleme elemanları arasında küçük farklılıklar olabileceğini belirtmeliyiz. Yukarıdaki listede seçeneklerle beraber ilişkilerin gösterimi yer almaktadır.Konuyu ele alırken kullandığımız örnek ise aşağıdaki gibi gösterilir.

Örneği okuyacak olursak diyagramdan “Personel en çok bir departmanda çalışabilir ve departmanların birden fazla çalışanı olabilir” ve “Personeller departman bağlı olarak çalışmak zorundadır.Departmanlar ise mutlaka bir personele sahip olmak zorunda değildir” anlamları çıkar.
Yukarda verilen basit ilişki örneğinin yanı sıra daha karmaşık ilişki örnekleri de bulunmaktadır.Bunları şöyle sınıflandırabiliriz:

• Yinelemeli ilişkiler (Recursive relationships)
• Supertip-Alttip ilişkileri (Supertype-subtype relationships)
• Bağımlılık ilişkileri (Dependent relationships)
• Kompleks ilişkiler (complex relationships)

Yinelemeli ilişkiler bir nesnenin kendiyle olan ilişkisidir.Örneğin personel’ler aynı zaman da bir yöneticiye bağlı olarak çalışmaktadır.Fakat yönetici kendisi de bir personeldir.Bu ilişki şu şekilde gösterebilir:

Şekilde “personel bir başka personele bağlı olabilir (opsiyonel) ve bir personele bağlı birden fazla personel olabilir (opsiyonel NULL dahil) “ ilişkisi gösterilmiştir.
Daha iyi anlaşılması açısından bir örnek daha verebiliriz.Vatandaş nesnesinde evlilik ilişkisini ele alalım.Bu ilişki her iki taraf açısından da opsiyonel (en çok bir ) durumdur.

Nesne ilişki diyagramında kolaylık ve gösterim açısından bazen bir nesnenin eşini (synonym) yaratarak da kullanabilirsiniz.İstenirse yinelemeli ilişkiler de aynı şekilde çalışılarak daha rahat gösterilebilir.

Supertip-Alttip İlişkileri (yada miras (inheritance) ilişkileri ) bir nesnenin bağlı olduğu nesnenin alt gurubu olması ya da ondan türemesi örneğinde geçerlidir.
Örneğin satış personeli , personel nesnesinin bir alt gurubunu oluşturur.Genel olarak personel niteliklerine sahip ve onun bir alt kolu olmasına rağmen bazı kendine özgü nitelikleri de vardır.(Satış tutarı gibi)

     Miras ilişkisinin gösterimi yukarıda örneklenmiştir.Yukarıdaki örnek “satış personeli de bir çeşit personeldir “ şeklinde okunabilir. (Bu yüzden supertype –subtype olarak adlandırılmıştır.)
      Miras ilişkisi aslında bire bir ilişkidir.Miras ilişkisi tanımlanırken çocuk nesne , ana nesnenin tüm özelliklerini ya da tanımlayıcı niteliğini miras alabilir.Burada ipucu olarak belirtmek gerekirse supertip’ten bağımsız bir alttip yaratmak istiyorsanız tüm nitelikleri miras almanız , eğer bir bağımlık yaratmak istiyorsanız sadece tanımlayıcı (anahtar) niteliği referans almanız gerekir.

       Bu ilişki türünde birden fazla alttip yaratılabilir.Supertip’in üyelerinin eğer sadece bir alt tip de yer alması isteniyorsa ortaklığa kapalı (mutually exclusive) alttipler yaratılabilir.Bunu diagramdaki küçük çarpı işaretiyle gösterebilirsiniz.

Bağımlılık İlişkileri bir nesnenin diğerine bağımlı olarak yaratıldığı bir ilişki türüdür.Ana nesne aynı zamanda alt nesneyi de kısmen tanımlar.Ebeveyn olmadan çocuk tek başına var olamaz.Örneğin müşteri hesabı ve müşteri nesnelerini ele alalım.Bir müşteri hesabının müşteri olmadan olması imkansızdır.

Kompleks ilişkiler üç ya da daha fazla nesne arasında olan ilişkilerdir.Ve her ilişki çokludur.
Bir şirket düşünelim.Bu şirketin çalışanları çeşitli rollere sahip olsunlar .Fakat her role sahip olabilmek için de rolle ilişkili kurslara katılmak gereksin.Aynı zamanda bir rol için de birden fazla kurs gerekebilsin.Bu durumun gösterimi şu şekilde olacaktır.

Fakat bu gösterim bazı hatalara yol açabilir.Örneğin personel ile kurs arasındaki tek ilişki personelin kurslara katılması değildir.Aynı zamanda kursunda verilmesi için personele de ihtiyacı vardır.
Bu durumda kursu veren mühendis ile , kurs almaya gelen mühendis birbirinden ayrılamaz.Bu durumu çözmek için ara bir nesne yaratılır.(Bir rol için kurs alan personel).

Kompleks ilişkiler için bir başka gösterim şekli de ilişkinin üzerinde nitelik tanımlamaktır.Başka bir deyişle iki nesne arasındaki ilişki nitelikle belirlenir.

Fakat bu method pekçok modelleme aracı tarafından desteklenmez.

Kavramsal Modelin Tamamlanması

Kavramsal modelin tamamlanması için modelin standard kontrolü ve gerçeğe uygunluğunun tescili gereklidir.Modelin gerçeğe uygunluğu sistem kabulü için tarafların bir araya gelimesi ve model üzerinde anlaşılması ile olur.
Fakat bu adımdan önce modelin doğruluğunun sınanması ve standarda uygunluğunun kontrol edilmesi gerekir.Kavramsal modelin kurallara uygunluğu şu şekilde sınanabilir.

• İki nesne arasında birden fazla ilişki tanımlanmamış olmalıdır
• Dairesel bağımlılıklar ve iki nesne arasında aynı bağımlılıklar olmamalıdır
• Dengelenmiş 1:1 ilişkiler kaldırılmış olmalıdır
• Hiçbir nesne bir diğer nesnenin aday anahtarını içermemelidir
• Yinelemeli ilişki içeren bir nesnenin başka bir nesneyle mutlaka ilişkisi olmalıdır

Bu kontrollerden sonra modelde direk olmayan ilişkiler ve bileşik nitelikler olup olmadığına dikkat edilmeli ve bu durumlardan kaçınılmalıdır.Kontrollere biraz açıklık getirmek ve örneklemek yerinde olucaktır.

Öncelikle aynı iki nesne arasında birden fazla ilişkinin bulunması kavramsal modelin esaslarıyla bağdaşmaz.Eğer kavramsal model doğru şekilde hazırlandıysa fazla ilişkiler olmamalıdır.Eğer böyle bir gereksinim varsa , tanımlanması unutulmuş nesne ( yada alttip) var olabilir.Bu durum kontrol edilip düzeltilmelidir.

İkinci kural olarak iki nesne arasında aynı bağımlılık olamaz.Bir nesne eğer var olmak için diğerinin üyesine ihtiyaç duyuyorsa , diğer nesne de varolmak için öbürüne ihtiyaç duyamaz.Örneğin bir departmanın kurulması için illa bir personele ve bir personelin alınması için illa bir departmana ihtiyaç duyulamaz.Çünkü açıkça bu durumda her ikisi de olamaz.

Benzer bir şekilde ikiden fazla nesne arasında da dairesel bağımlılık yaratılmamalıdır.

Yukarıdaki örnekte olduğu gibi bir ilişki aynı şekilde hiçbir nesnenin olamaması sonucunu doğurur.Yukarıdaki daire de en az bir nesne bağımlı olmamalıdır ki diğer nesneler de var olabilsin.

Dengelenmiş 1:1 ilişkiden kasıt 1:1 ilişkilerde her iki nesne içinde ilişkinin aynı şeçenekle yaratılmış olmasıdır.

Eğer ilişki iki taraf içinde kesinlikle bir şeklinde tanımlanmışsa her iki nesne de var olamaz.Bu durum genellikle bir nesnenin yanlışlıkla iki parçaya ayrılmış olmasından kaynaklanır.(Ya da iş tarifi hatalıdır)

Eğer iki taraf için de en fazla bir durumu var ise bu durum aslında bir nesnenin diğerinin alt tipi olduğunu bir göstergesidir ya da modelde henüz gösterilmemiş bir süper tip vardır ve her iki nesne de birer alttip ‘dir.

Nesnelerin diğer nesnelerin aday anahtarlarını içermemeleri konusuna gelince ilişki bağımlılık veya supertip-alttip şeklikde değilse muhtemelen yanlış tanımlanmış nitelikler sözkonusudur.Kavramsal modelde dış anahtar (foreign key) tanımı yoktur.Ve ilişkiler de kavramsaldır.

Direk olmayan ilişkiler ise gereksizdir.Bu tip ilişkiler zaten sağlanmış olan birşeyin tekrarıdır.Örneğin departmanların altında çalışma gurupları ve guruplara bağlı çalışan personellerin olduğunu düşünelim.

Bu durumda yukarıdaki gösterimde personel ile departman arasındaki ilişki kesinlikle gereksizdir.Bunun yerine aşağıdaki model daha doğrudur.

Bileşik niteliklerdense mümkün olduğunca kaçınmak gereklidir.Bileşik nitelikden (composite attributes) kasıt birden fazla niteliğin , tek bir nitelik altında toplanmasıdır.Örneğin adres bilgisi sokak adresi , şehir , posta kodu gibi niteliklerin birleşmesinden oluşsun.Bu durum daha sonra hem kuralların tanımlanması , hemde verinin işlenmesinde çok çeşitli sorunlara yol açıcaktır.Örneğin 5 numerik karakter’den oluşan posta kodunun gerçektende böyle yazılabilmesi için çok fazla efor sarf etmeniz gerekecektir.

Tüm bu kontroller ve incelemelerden sonra oluşturulan nitelik alanları (attribute domain) ve nitelik tanımları dikkatlice gözden geçirilmeli , ilerde değişiklik gösterebilecek nitelikler buna uygun olarak tanımlanmalıdır.Örneğin fiyat alanları enflasyon sonucu bir sene sonra yetersiz hale gelmemelidir.

MANTIKSAL MODELİN HAZIRLANMASI

Mantıksal model , kavramsal modelin fiziksel modele uyarlanmaya hazır hale getirilmiş halidir.Fiziksel model için kavramsal modeldeki nesne kavramları tablolar haline getirilir , tablolara anahtarlar atanır ve bunlar üzerinden ilişkiler yabancı anahlar şekline çevrilir.Normalizasyon adımlarından geçilerek mantıksal model tamamlanır.

Nesnelerin Tablolar Haline Çevrilmesi
Mantıksal model içinde , kavramsal modelde hazırlanmış olan nesneler artık tablolar halinde düşünülür.

Yukarıdaki ERD’de yeralan nesnelerin tablolara dönüştürülmüş hali şöyledir.

YAYINCI

Yayinci No	Adi	Telefonu	Adresi
4680	Adam Yayınları	212-4456824	Yeniyol sk 5 Besiktas
32110	Can Yayınları	216-5534668	Duru sk 12/3 Acıbadem

           Tablo başlık ve vücut olmak üzere iki kısımdan oluşur.Başlık tablo adı ve kolonlardan , vücut kısmı ise satırlardan oluşur.Bir tablo vücut kısmında aynı iki satır olamaz.Benze şekilde başlık kısmında da aynı iki kolon adı bulunamaz.Bu tablonun herhangi bir satırının , herhangi bir kolonu yalnız bir değer alabilir.
         Bir nesne bu kurallara uyduğunda ilişkisel modelle de tanışmış sayılır.Satırlar özel bir dizilişte değildirler , bu nedenle de tablo içindeki sıra numarasına göre tanımlanamazlar.Sonuç olarak ana anahtar (primary key) satır üzerinde işlem yapabilmek için tek güvenli yoldur.Ana anahtar tablonun her satırını tanımlayabilen kolon yada kolonlardan oluşur.

1. Normal Form

    Normalizasyon beş adımda modele uygulanan bir süreçtir.Daha geniş tanımı daha sonraki konularda ele alınacaktır.
Eğer tablonun her bir satırının , her bir kolonu yani eğer tek bir değer taşıyorsa birinci normal form oluşmuş demektir.Diğer bir deyişle bir hücre iki niteliği bir arada barındırmamalıdır.Yani ad ve telefon gibi iki ayrı nitelik aynı hücrede yer almaz. Bu özellik aynı zamanda atomik olarak adlandırılır.Çünkü daha küçük hücreler yaratılamaz.
Genellikle üç çeşit nitelik 1. Normal forma geçerken sorun çıkarır:
1. Bileşik nitelikler (composite attributes)
Birden fazla alanın birleşmesinden oluşmuş bu tip kolonlar atomik hale çevrilmelidir.Örneğin konteyner numarası niteliği firma numarası ve ürün numarası gibi alanlardan oluşuyorsa bu alanlar ayrılar ayrı kolonlar oluşturulmalıdır.
2. Çoğul nitelikler (plural attributes)
Bazen bir nitelik birden fazla değer alabilir.Örneğin telefon numarası niteliği bir müşterinin birden fazla telefonu olabilmesinden dolayı çoğul bir nitelik oluşturur.Bu durumda ya birden fazla kolon yaratılarak (telefon 1 , telefon 2 …) sorun giderilir , ya da telefon numaraları için ayrı bir nesne yaratılarak (müşteriye bağımlı) çözüm üretilir.Bu durumda ikinci bir tablo da oluşturulur.
3. Kompleks veri tipindeki nitelikler
Video klip , vektor grafikleri gibi veriler karmaşık veri tiplerindedirler.Bunlar üzerinde atomik olup olmamaları üzerine tartışma yürütülebilir.Örneğin eğer bir video klibin tek tek sahnelerine ihtiyaç duyulmuyorsa klip atomik sayılabilir , aksi halde sahne sahne parçalanarak atomik hale getirilmelidir.

Ana Anahtar (Primary Key) Atanması

Bu aşamada aşağıdaki kriterlere uyan aday anahtarlardan biri ana anahtar olarak seçilir.
1. Tanımlanabilir bir değere sahip olmalıdır(Null içermemelidir)
2. Sürekli olmalıdır (Değeri değişmemelidir)
3. Minimal olmalıdır (Mümkün olduğu kadar az veri içermelidir)
4. Şifrelenmiş değer içermemelidir
5. Bütün database kullanıcıları tarafından erişilebilir olmalıdır

Eğer bu kurallara uygun bir anahtar bulunamıyorsa o zaman yapay bir anahtar oluşturulabilir.Bunun dışında eğer bulunan anahtarlar çok büyük veri içeriyorsa yada içerdikleri veri eğer hassas ve gizli tutulması gereken birşeyse o zaman da yapay anahtar oluşturulabilir.
Bunlar dışında kavramsal model oluşturulurken değinilen anahtar oluşturma kriterleri unutulmamalıdır.En önemli kriter anahtarın tablo boyunca kendini tekrar etmemesidir.

Yabancı Anahtar (Foreign Key)

Ana anahtar nesne üyelerinin , mantıksal modelde tablo satırlarının tanımlanmasında kullanıldığına göre , kavramsal modelde tanımlanan ilişkilerin , mantıksal modelde bu anahtarlar üzerinden tanımlanması gerekir.
Bir nesnenin diğer bir nesneyle ilişki kurması ancak ana anahtar üzerinden olabileceğinden , tablonun ilişkide bulunduğu diğer tablo yada tabloların anahtarını da içermesi gerekir.Bir tablonun ilişkiyi tanımlamak üzere içerdiği diğer tablo anahtarına yabancı anahtar (foreign key) denir.Yabancı anahtar aynı zamanda tablolar arası ilişki de tanımlar.
Yabancı anahtarın aldığı değerler mutlaka referans alınan tablo içinde bulunurlar.Aksi taktirde veri tabanı yöneticisi böyle bir veri girişine izin vermez.Bu durumun tek istisnası yabancı anahtar için tanımlanan kolonların NULL değer alabileceğini belirtmektir.Bu durum 1:1 ilşkide en çok bir ve M:1 ilişkide herhangi bir sayıda seçeneklerinin aktarılmasında kullanılır.

Yukarıda görüleceği üzere yazar tablosu yayinci tablosunun ana anahtarını kendi kolonları arasına almıştır.Yayinci_no yazar tablosundaki yabancı anahtardır.

Supertip-alttip ilişkisinin mantıksal modele taşınması sırasında yapılacak şey alttip’in süper tip ile aynı ana anahtara sahip olması ve ana anahtarın aynı zamanda yabancı anahtar da olmasıdır.

Kavramsal modeldeki bağımlılıkların taşınması sırasında ise bağımlı olunan nesnenin ana anahtarının bağımlı nesnenin ana anahtarında yer alması ve bileşik anahtar oluşturulması şeklinde bir yol izlenir.

Çoklu : Çoklu İlişkilerin Taşınması

Çoklu:Çoklu ilişkiler mantıksal modele olduğu gibi taşınamazlar.Tablonun bir satırında diğer tabloyla ilgili yalnızca bir tane anahtar bulunabileceğinden bunun çözümü ancak ara tablolar yaratılmasıyla mümkün olur.

Yaratılan ara tabloda her iki tablonunda primary key’I referans alınarak bu sorun çözümlenir.

Diğer İlişki Tipleri
Kompleks ilişki tipleri daha evvelden kavramsal model içinde çoklu:çoklu ilişkiyi çözmüş olduğundan , ara nesne için yaratılan tabloda referans tabloların anahtarları foreign key ve bileşik ana anahtar olarak tanımlanarak taşınır.
Yinelemeli ilişkilerin taşınmasında ise tablonun ana anahtarının başka bir kolon adıyla yaratılarak yabancı anahtar oluşturulması gerekir.

NORMALİZASYON

Daha evvelde bahsettiğimiz gibi normalizasyon beş adımdan oluşan bir süreçtir.Bu adımlar aslında kolonların doğru yerde yer alıp almadığını , ek tablolar gerekip gerekmediğini tespit eden , kısaca modeli en efektif hale getirmemizi sağlayan bir yoldur.Adımları kısaca tarif edecek olursak

1NF Eğer tablonun her kolonunun , her satırı tek bir tip veri tutuyorsa 1. Normal formdadır.Her hücre atomik olmalıdır.

2NF Eğer tablonun her kolonu ana anahtara fonksiyonel bağımlıysa ikinci normal formdadır.Örneğin aşağıdaki örneği ikinci normal forma getirebilmek için Resmin tutulacağı ikinci bir tabloya ihtiyaç vardır.

Başka bir örnek de bileşik anahtar dan verilebilir.

Bu tablonun 2NF uyması için yine iki tabloya ayrılması gerekmektedir.Başka bir deyişle bağımlılık ana anahtara göre olmak zorunda olduğundan , tablo buna uygun olarak bölünür.
2NF’un temel amacı farklı fonksiyonlar için erişilecek veri sayısını en aza indirmektir.Örneğin yukardaki örnekte 2NF ‘a uyulmaması halinde Eyalet adına erişmek için gereksiz pekçok veri okunacakdı.

3NF üçüncü normal form için tablonun anahtarı ile kolonları arasında geçişli bağımlılık kalmamalıdır.Tüm kolonlar direk olarak anahtara bağlı olmalıdır.

Örnekte katalog tablonun anahtarı olduğu halde renk aslında ürün koduna bağımlıdır. Katalog ile renk arasında ürün üzerinden geçişli bağımlılık vardır.Bir ürünün rengini bulabilmek burada son derece gereksiz veri okumaya yol açıcaktır.Bu durumdan kurtulmak için tablo bölünerek 3NF’a uygunluk sağlanır.

Boyce/Codd Normal Form 3NF’in içinde bir adım sayılmasına rağmen yukardaki işlemler sonucu henüz model BCNF’e dönüşmüş değildir.3NF içinde aslında tüm geçişli bağımlıklarda kaldırılmasına rağmen , tablo henüz yeterince normalize olmuş değildir.Carlo Zaniolo 3NF’u şu şekilde tanımlar .
R bir tablo olsun.Bu tablo içinde X bir gurup nitelik ve A da sadece tek bir niteliği temsil etsin.Eğer A’nın X’e fonksiyonel bağımlılığı var ise (X => A) , R tablosu 3NF’a uymak için aşağıdaki şartlardan en az birine uymalıdır:

• X kümesi A’yı kapsamalıdır
• X kümesi R’nin en az bir aday anahtarını içermelidir
• A tablonun bir aday anahtarı tarafından kapsanmalıdır

BCNF ile 3NF’in farkı BCNF’in üçüncü maddeye izin vermemesidir.
Başka bir deyişle birden fazla bileşik aday anahtar içeren tablolarda , eğer aday anahtarların içerdiği ortak bir nitelik var ise , bu iki aday anahtarın niteliklerinden herhangi biri diğer aday anahtarlardan birine fonksiyonel olarak bağımlı olamaz.

Şekilde A + B bileşik aday anahtar ve B + C bileşik aday anahtar göstermekte A => C bağımlılığı bulunmaktadır.Bu durum 3NF ‘e uygun olabileceği halde BCNF’e uygun değildir.
Bunu bir örnekle gösterelim.

KOMİTE

Komite Adı	Element	Atom No	Yıllık Toplantı
Ticaret	Altın	79	6
Madencilik	Bakır	29	2
Enerji	Uranyum	92	4
Finans	Altın	79	5

Tablonun aday anahtarları şu şekilde olsun :

Tablo bu haliyle 3NF’a uygundur.Tablo üzerindeki bağımlılıkları şu şekilde listeleyebiliriz:

Element + Komite adı => Yıllık Toplantı

Atom No + Komite adı => Yıllık Toplantı

Element <= => Atom No

           Burada BCNF’e uymayan son bağımlılıktır.Ve tablo yeterince normalize edilmemiştir.Bunun zararlarına şu şekilde örnek gösterebiliriz:

            Eğer 79 ‘nolu elementin adı değişirse bütün tablo aranacak ve pek çok kayıt okunduktan sonra adı değişecektir.Ya da eğer madencilik komitesini silerseniz 29 nolu elementi de kaybedersiniz.
           Çözüm için bağımlılığın olduğu kayıtların başka bir tabloya çıkarılması yeterlidir.Bu durumda aşağıdaki şekilde iki tablo oluşacaktır.

KOMİTE

Komite Adı	Atom No	Yıllık Toplantı
Ticaret	79	6
Madencilik	29	2
Enerji	92	4
Finans	79	5

ELEMENT

Atom No	Element
79	Altın
29	Bakır
92	Uranyum
79	Altın

BCNF’den sonra aslında pek çok durum için normalizasyon tamamlanmış sayılır.Aşağıdaki durumlarda normalizasyon tamamlanmıştır

• Eğer tablo 3 ya da daha az kolona sahipse
• Eğer tabloda hiç bileşik aday anahtar kalmamışsa
• Eğer tabloda en az bir aday anahtar bileşik değilse otomatikman 4NF tamamlanmıştır.Direk 5NF işlemlerine başlanabilir

Genellikle yapay anahtar kullanımı 3NF’dan sonra 4NF’u da geçmenizi sağlar.Çünkü yapay anahtarlar bileşik değildirler.Özellikle şu tablolar 4NF ve 5NF’a ihtiyaç duyarlar:

• Ana anahtarın bütün niteliklerin birleşmesiye oluşturulduğu tablolar
• Ortak çalışılan tablolar.Çoğul : çoğul ve karmaşık ilişkilerin çözümünde yaratıldığı gibi.
• Çoğul nitelikler için yaratılan ek tablolar

4NF ‘de tablo üzerindeki çoğuldeğerli bağımlılıklar (multivalued dependencies) çözülür.Çok değerli bağımlılıklar direk bir fonksiyonel bağımlılık olmamasına rağmen bir fonksiyonel bağımlılık yaratırlar.Örneğin aşağıdaki müşteri dağılım tablosuna bakalım.

Bölge	Satış Temsilcisi	Müşteri
Ege	Ahmet	Selçuk Gıda Market
Ege	Ahmet	Özkan Otel
Ege	Ahmet	Gerçek Tur. İşletme
Ege	Cem	Selçuk Gıda Market
Ege	Özhan	Kocaman Market
Marmara	Cem	Güleli Market
Marmara	Cem	Moralı Tic.
Marmara	Selim	Çınar Market
Marmara	Selim	Moralı Tic.

Tabloda bir bölgede bulunan müşterilere hizmet veren satış temsilcileri gösterilmiştir.Aynı zamanda bir satış temsilcisi birden fazla bölgede de görev yapabilmektedir.
        Yukarıdaki tabloda hiçbir fonksiyonel bağımlılık olmaması rağmen aynı zamanda hatırı sayılı bir gereksizlik de vardır.Örneğin yeni bir müşteri tanımı için iki satır gerekebileceği gibi , satış temsilcisinin ismini değiştirmek için üçden fazla satır üzerinde değişiklik gerekebilir.
Yukarıdaki tabloda bir çift kolonun ve bir veri kümesi arasında bağımlılık vardır.Örneğin Ege bölgesi ve Ahmet isimli satış temsilcisi bir müşteri kümesini gösterirken Marmara bölgesi ve Moralı Tic bir gurup satış temsilcini göstermektedir.

          Eğer her A ve B nitelik çifti için bir C niteliği kümesinden bahsediliyorsa ve aynı zamanda aşağıdaki şartlarda varsa A ile C arasında çoğul bağımlılık vardır :

• A ve B nitelik çifti aynı olduğunda , her zaman aynı C kümesi alınabiliyorsa
• C’nin değeri A’nın değerine bağımlıysa
• C’nin değeri B’nin değerine bağımlı değilse

Çoğuldeğerli bağımlılık çift okla gösterilir.

Bölge =>> Müşteri

Çoğuldeğerli bağımlılığın doğası gereği eğer
     A =>> C şeklide bir bağımlılık varsa , aynı zamanda A =>> B şeklinde de bir bağımlılık vardır.

Müşteri dağılım tablosu için bu şu şekilde gösterilebilir:

Bölge > Satış Temsilcisi

Bu yüzden genellikle çoğul bağımlılıklar şu şekilde gösterilir:

Bölge =>> Satış Temsilcisi | Müşteri

Tablo 4NF için bölünerek iki tablo ortaya çıkarılır.Bölünme için şu formül kullanılır:

                                  IF A =>> B | C THEN A => B AND A => C

Bölge	Satış Temsilcisi
Ege	Ahmet
Ege	Cem
Ege	Özhan
Marmara	Cem
Marmara	Selim

Bölge	Müşteri
Ege	Özkan Otel
Ege	Gerçek Tur. İşletme
Ege	Selçuk Gıda Market
Ege	Kocaman Market
Marmara	Güleli Market
Marmara	Moralı Tic.
Marmara	Çınar Market

Eğer ortaya çıkan tabloların satır sayıları ve üzerinde yapılacak işlemler denenirse 4NF’un faydaları kolayca ortaya çıkar.

5NF ise birleşmiş bağımlılıkların (join dependency) ortadan kaldırılmasıdır.Şimdiye kadarki çözümlerde genellikle tablo ikiye bölünerek sorun giderildi.Fakat bazı durumlarda tablo ikiye bölündüğünde mevcut ilişkileri korunamazken üç ya da daha fazla tabloya ayrılarak ilişkiler korunabilir.
Bozulmadan üç yada daha fazla tabloya bölünen tablolar birleşmiş bağımlılıklar üretir.Bu da aynı zamanda tablonun üç yada daha fazla nesne ile ilişkisinin olmasını gerektirir.Problem genellikle komplex ilişkilerde karşımıza çıkar.
Örneğin bir senfoni orkestrası düşünelim.Bu orkestra Beethoven eserlerini seslendirdikleri bir dizi konser veriyor olsunlar.Müzisyenler birden fazla enstruman çalabilsin.Senfonilerin seslendirilebilmesi için birden fazla enstruman gereksin.Müzisyenler konserlerde sadece uzmanı oldukları enstrumanları çalsınlar.Bu durumu şu ER diyagramı ile gösterelim.

Burada problem konserde müzisyenlerin her enstrumanı çalabilecekleri izleniminin yaratılması ve buna izin verilmesidir.Problem 5NF’a göre düzenlenerek problem giderilir.Bunun için tekrar kavramsal modele dönülüp aşağıdaki şekilde bir düzenleme yapılır.

NORMALİZASYONUN AVANTAJLARI
     Normalizasyon adımlarını tanımladıktan sonra , bu sürecin bize genel olarak sağladığı sonuçları listelersek :

• Gereksizliklerin Azaltılması
         Normalizasyon yapılmamış tablolar üzerinde sıkça veri tekrarı görülür.Normalizasyon verinin en az tekrarını ve gereksiz tekrarın ortadan kaldırılmasını garanti eder.
• NULL ihtiyacının en aza indirilmesi
          NULL genellikle numerik verilerin kullanımında sıkça problem yaratır.Örneğin toplam ya da ortalama almak gibi.NULL aynı zamanda henüz belirlenememiş bir supertip’in belirtisidir.
• Çevrilebilirlik
         Normalizasyon da sıkça bir tabloyu bölmek zorunda kalırsınız.Tablolar yeniden düzenlendiğinde orjinal veri kaybolmaz ve sahte veri üretilmez.

DİZAYNIN TAMAMLANMASI

Dizaynın tamamlanması için mantıksal dizaynın hazırlanmasından sonra kalan iki süreç fiziksel dizaynın hazırlanması ve modelin uyarlanmasıdır yani hayata geçirilmesidir. Fiziksel dizayn veri tabanında kullanılacak saklama aygıtlarının tamamlanması , tabloların üzerinde performans için indexlerin yaratılması , tabloların aygıtlara atanması vb. süreçleri içerir. Modelin uyarlanması ise artık herşeyiyle hazır olan modelden bir veri tabanı yaratılmasıdır diyebiliriz.Bu süreçler seçilen veri tabanı yönetim sistemi ile oldukça ilişkilidir.
               Bu süreçler ele aldığımız konunun dışına taştığı için bu kadar bahsetmek yeterlidir.Bu aşamada en çok söz sahibi olan veri tabanı yöneticileridir.Bu süreçler veri tabanının yaşam döngüsü içersinde en çok dinamiklik gösteren , oldukça değişikliğe ve yeniliğe uğrayan süreçlerdir.

Kurumsal SOA

2011-04-20T14:27:00.002+03:00

Oracle Day 2009'da yaptığım Kurumsal SOA hakkında bir sunum

Kurumsal SOA

View more presentations from Serhat Dirik

Yazılım Ölçümleme

2011-04-19T11:15:00.010+03:00

Bir önceki yazımda nesne yönelimli yazılımda dizayn prensiplerini işlemiştim.Okurların bu yazıda bahsedilen metriklerin nereden kaynaklandığını daha iyi algılamaları açısından, dizayn prensiplerine göz atmalarını öneririm.

Yazılım ölçümlemede kullanılan metrikleri temel olarak iki kategoriye ayırabiliriz :

Ürün Kalitesi ile ilgili metrikler

Kalite , büyüklük , modulerlik vb

Süreç maliyet/kaynak planlaması ile ilgili metrikler

Efor , zaman cetveli , kaynak gereksinimi

Bu yazıda nesne yönelimli yazılımda kalite ölçümlemede kullanılabilecek metrikler üzerinde durulmuştur.Yazıda nesne yönelimli programlaya özel yöntemlerin yanı sıra geleneksel yöntemlerden ; nesne yönelimli programlamaya aktarılan yöntemler de ele alınmıştır. Nesne yönelimli yazılımlara her ne kadar bir kısım geleneksel ölçme yöntemleri kullanılabilse de genel olarak kullanılabilen metrikler geleneksel yöntemlerden oldukça farklıdır.

Yapılan araştırmalarda yazılım süreçlerinde bakım maliyetlerinin , geliştirme maliyetlerinin neredeyse iki katı olduğu gözlenmiştir.Bu bize kaliteli yazılım üretmenin zorluğunu göstermektedir.

Yazılımın kalitesinin garanti altına alınması ve iyileşme sağlanabilmesi , sürekli ölçümleme ve iyileştirme ile olabilir.Gerekli iyileştirmeler ölçümleme sonucu elde edilen bilgilere dayanılarak yapılabilir.Ölçümleme yapılmadan hazırlanan eylem planları kesinlikle gerekçesiz ve gelişigüzel olacaktır.

Geleneksel Metrikler

Bu bölümde ele alınan metrikler geleneksel metriklerden nesne yönelimli yazılıma uyarlanabilecek olanlardır.

Kod Büyüklüğü (Lines Of Code LOC)

Geleneksel olarak yazılımın boyutu satır sayısı ile ölçülür. Satır büyüklüğü çeşitli şekillerde ölçülür :

Satır Sayısı ( Lines Of Code – LOC ) ölçümü programın tüm satırlarının sayılmasıdır.

Yorum ve boşluk içermeyen (Non-comment Non-blank NCNB veya Source Lines Of Code SLOC ) programın yorum satırları ve boş satırlardan arındırılmış halidir.

Çalıştırılabilir yordam sayısı (Executable Statements EXEC) program içinde yer alan yordam sayısıdır.

Örneğin aşağıdaki kod :

IF X = 3

// Comment Line

Then
Y = 10

4 LOC , 3 NBC ve 1 EXEC olarak sayılır

Satır büyüklüğü pek çok dile uyarlanabildiği için oldukça kullanışlı ve ölçümü beklenen bir metriktir.Ancak satır büyüklüğü üzerine yorum yapmak için dilin karmaşıklığı , projenin karmaşıklığı gibi faktörler de göz önünde bulundurulmalıdır.Yazılım istatistiklerini biriktiren şirketler yeni projelerin faktörlerini göz önüne alarak , kestirimlerde bulunabilirler.

Satır büyüklüğünün küçük olması yazılım için hedef olmalıdır.

Yorum Oranı (Comment Percentage - CP)

Yorum oranı (Comment Percentage CP) programın için hazırlanmış yorum satırlarının (kod ile birlikte ya da dışarıda) , toplam programın yorum ve boşluk içermeyen satır sayısına (SLOC) bölümü ile bulunur.Yüksek yorum oranı programların anlaşılabiliğini arttıran ve bakımını kolaylaştıran bir faktördür.

Yorum oranının %20 ila %30 arası olması tavsiye edilen bir durumdur.

Döngüsel Karmaşıklık (Cyclomatic Complexity -CC)

Thomas J. McCABE tarafından ortaya konan bu metrik bir methodun içindeki algoritmanın karmaşıklığını ölçmek için kullanılır.Aynı zamanda bir methodun test edilmesi için gerekli test durumu sayısını da verir.

CC = yollar – düğümler + 2

şeklinde hesaplanır.Örneğin bir IF cümlesi iki seçeneğe sahiptir.Eğer şart doğru ise birinci yol test edilmiş olur , hatalı ise ikinci yol test edilir.Aşağıdaki şekilde hesaplanış ile ilgili örnekler verilmiştir.

Methodların düşük karmaşıklığa sahip olması tercih edilir.Bu kodun anlaşılırlığının ve test edilmesinin kolay olduğunu gösterir. Döngüsel karmaşıklık , nesne yönelimli yazılımda kalıtım ilişkisi yüzünden bir sınıfın karmaşıklığını ölçmek için kullanılamaz.Fakat methodların karmaşıklığının toplamı , sınıfın karmaşıklığı olarak kabul edilebilir.Bir method için karmaşıklığın 10’u aşmaması tercih edilmelidir.Ancak 20’ye kadar kabul edilebilir.Bunu aşan değerler anlaşılması oldukça güç kodları gösterir.

Nesne Yönelimli Metrikler

Sınıf Temelli Metrikler

Nesne yönelimli programlamada temel birim sınıftır.Bu bölümde yer alan metrikler sınıf temelli metriklerdir.Sınıf ve onun temel elemanları üzerinden alınan metrikler ile tüm ürün kalitesi hakkında genel fikirler verir.

Sınıf Method Sayısı (Number Of Methods per Class -NOM)

Sınıf başına düşen method sayısı sınıfın karmaşıklığı açısından bir göstergedir.Aynı zamanda fazla method sayısı arabirimin ayrılması prensibine ( the interface segregation principle ) aykırı durumların da habercisidir.

( Ortalama method sayısı = Toplam Method Sayısı / Toplam sınıf sayısı formulü ile ortalam method sayısı elde edilir.)

NOM değerinin 20 ‘nin altında kalması tercih edilmelidir. 40’dan küçük değerler de kabul edilebilir sınırlar içindedir.Ancak bu değerler sınıfların constructor , destructor ve ayrıca mutator (getxxx , setxxx gibi) methodlarının dahil edilmiş hali olarak kabul edilmelidir.Bu tip methodlar ayıklanmış haldeyken sınıfın method sayısının 10’u geçmemesi tercih edilmelidir.

Büyük NOM değerleri anlaşılması , yeniden kullanımı ve bakımı güç sınıflara işaret eder.

Chidamber ve Kemerer Metrikleri

1. Sınıf Başına Ağırlıklı Method (Weighted Methods per Class -WMC)

Döngüsel karmaşıklık değerleri toplamının sınıf sayısına bölümü ile bulunur.WMC değerinin 100’ün altında olması tercih edilmelidir.WMC sınıf karmaşıklığı hakkında fikir veren en önemli donelerden biridir.Bu metriğin faydaları sınıf başına ortalama method sayısı gibi değerlendirilebilir.WMC değerinin 100’ün altında olması kabul edilebilir bir değerdir. WMC değeri NOM’dan farklı olarak sınıfın karmaşıklığı hakkında daha net bir fikir verir.

Bu metrik üzerinden genel olarak elde edilebilecek fikirler şu şekilde sıralanabilir :

WMC sınıfın karmaşıklığı hakkında fikir verir ve harcanacak geliştirme ve bakım eforları için gösterge sayılabilir
Büyük sayıda method içeren sınıfların üzerinde yapılacak değişiklikler , sınıftan türiyen sınıflar üzerinde potensiyel etkiye sahiptir
Daha fazla method içeren sınıflar daha uygulamaya özel ve yeniden kullanımı zor sınıflar olarak görülürler

Ekli grafikte örnek bir WMC dağılımı verilmiştir.Bu grafik yardımıyla projenin toplam karmaşıklığı hakkında fikir edinilebilir.WMC değeri 100’ün üzerindeki sınıfların yeniden ele alınması faydalı olacağından bu sınıf sayıları tablodan kolaylıkla seçilmektedir.

2. Kalıtım Ağacının Derinliği (Depth of Inheritance Tree - DIT)

DIT metriği sınıfın ebeveyn sınıflarının sayısını gösterir.Eğer çoklu kalıtım durumu söz konusu ise bu durumda hiyerarşideki en uzun yol kabul edilir.

Örneğin yukarıdaki şekilde yer alan D sınıfı için DIT değeri 2 olarak kabul edilir.DIT bize kısaca kaç tane ana sınıfın potensiyel olarak sınıfımızı etkileyebileceğini gösterir.

Sınıf hiyerarşisinin derinliği arttıkça daha fazla method kalıtım alınır ve sınıfın davranışlarını öngörmek ; anlamak zorlaşır.
Derin hiyerarşiler daha fazla method ve sınıf etkilendiğinden , dizaynı karmaşıklaştırır
Ancak hiyerarşi derinleştikçe kalıtım alınan methodların yeniden kullanım potensiyeli artar

DIT metriğine destekleyici olarak sınıfın kalıtım aldığı method sayısı (number of methods inhertied NMI) da ölçülebilir.

DIT için önerilen rakam genellikle 5’in altında olmasıdır. 5’in üzerindeki derinlikler oldukça karmaşık yapılar doğurabilir.DIT’in 0 olması sınıfın kök olduğunu gösterir.DIT’in ortalam 2-3 arası bir değerde olması yeniden kullanımın iyi seviyede olduğunu gösterir.2’den küçük derinlikler ise yeniden kullanımın zayıf olduğu alanları işaret eder.

Ekli grafikte örnek bir DIT dağılımı gösterilmiştir.

3. Alt Sınıf Sayısı ( Number of Children - NOC)

NOC metriği sınıftan türemiş alt sınıflarının sayısını verir.

· Alt sınıf sayısı çoğaldıkça kalıtım özelliğine bağlı olarak yeniden kullanımın arttığı anlaşılır

· Alt sınıf sayısının çokluğu sınıfın hatalı soyutlama yapıldığını , belki de hatalı bir hiyerarşi kurulduğunu gösterebilir.

· NOC sınıfın nüfus alanı hakkında bir fikir verir.NOC metriği yüksek sınıflar gözden geçirme , test gibi süreçlerin daha dikkatli ve uzun tutulması gereken yerlerdir.

DIT ve NOC metriklerinin kendi içinde getiri ve götürüleri vardır.Yüksek DIT değerleri artan karmaşıklığı gösterirken aynı zamanda artan yeniden kullanıma da işaret eder.Aynı şekilde yüksek NOC değeri artan yeniden kullanıma işaret ederken daha fazla test eforu harcanması gerektiğini gösterir.Ekli şekilde DIT ve NOC metriklerinin bir arada dağılımları gösterilmiştir.Bu tablodan bazı garip durumlar saptanabilir.Örnek şekilde ağacın üçüncü seviyesinde ancak 40 alt sınıfa sahip bir sınıf göze çarpmaktadır.

4. Nesneler Arası Eşleme (Coupling Between Object Classes - CBO)

CBO değeri sınıfın kalıtım ilişkisi dışında diğer sınıflar ile kurduğu bağımlılık (eşleme) sayısını gösterir.Örneğin diğer bir sınıfın methodlarının kullanılması ya da diğer sınıfın bir nitelik olarak tanımlanması vb. CBO değeri eşleme yapılmış sınıf sayısını gösterir.Örneğin bir A sınıfı methodları içerisinde diğer B sınıfına dört şekilde mesaj gönderiyor olsun.Bu durumda A ile B sınıfı arasında yalnız bir eşleme vardır.Eşleme sayısı gönderilen mesaj sayısı ile ilgili değil kaç farklı sınıf ile haberleşildiği ile ilgilidir.

· Sınıflar arası çok sayıda eşlemenin bulunması moduler dizaynı zedeler ve yeniden kullanımı engeller.Bağımsız sınıfların başka uygulamalar içinden yeniden kullanımı daha kolaydır.

· Modulariteyi ve kapsullemeyi düzenlemek için eşlemeler minimum düzeyde tutulmalıdır.Eşleme sayısının yüksek olması sınıfın değişikliklere karşı daha hassas ve bakımının daha zor olmasına yol açar.

· CBO değeri dizaynın çeşitli kısımlarında uygulanacak testin ne kadar karmaşık olacağı hakkında bir fikir verir.Yüksek değerler daha zor testlerin yapılacağının göstergesidir.

CBO değeri sınıfın bağımsızlığının göstergesidir.CBO ve DIT değerleri 0 olan sınıflar tamamen bağımsız olarak çalıştırılabilir sınıflardır.

CBO değerinin 5’i aşmaması genellikle tavsiye edilmektedir.Ekli şekil örnek bir CBO grafiğini göstermektedir.

5. Sınıf Yanıt Sayısı (Response for a Class - RFC)

RFC sınıfın içindeki method sayısı + methodlar tarafından çağırılan method sayısının (her method sadece 1 kez sayılmak üzere) toplamıdır. Formulü :

RFC = |RS|

RS = { M }È all i { Ri }

( { Ri } = I methodu tarafından çağırılan unique method sayısı ve { M } = sınıfın methodları )

şeklinde ifade edilebilir.RFC sınıf tarafından bir mesaja cevap için potensiyel olarak çalıştırılacak method sayısını verir.Buna sınıf hiyerarşisi içerisinde erişilebilecek tüm methodlar dahildir.Bu metrik sınıfın method sayısı ile diğer sınıflarla kurulan iletişim sayısının toplamı gibi görülebilir.

RFC metriğinin sınıf başına 100’den aşağı olaması kabul edilebilir bir durum olsa da 50’yi aşan bir sınıf genellikle pek görülmez.

RFC değerinin yüksek olduğu sınıfların anlaşılması daha zor olacağından için test ve debug eforları daha fazla olacaktır
RFC değeri yükseldikçe sınıfın karmaşıklığı artar
RFC değeri ayrılacak test zamanının hesaplanmasına yardımcı olabilir

Aşağıdaki grafikte sınıflara göre RFC dağılımını göstermektedir.

RFC / NOM değerinin C++ için 5’i Java için 10’u aşmaması tavsiye edilmektedir.Ekli grafikte bu kurala uyan ve uymayan sınıflar gösterilmeye çalışılmıştır.

RFC > 5 x NOM

6. Uyumsuzluk (Lack of Cohesion - LCOM)

Uyumluluk nesne yönelimli programlamada oldukça önemli bir kavramdır.Bir sınıf elemanlarının birlikteliğinin derecesini gösterir.İyi bir dizayn yüksek uyumlulukta sınıflar sunmalıdır.

Uyumluluk bir sınıfın birden fazla soyutlama yapmamasını gerektirir.Aksi durumda sınıfın başka sınıflara bölünmesi gereklidir.

Chidamber ve Kemerer’a göre sınıfın aynı değişkenlerine erişen birden fazla method varsa sınıfta bir uyumluluktan bahsedilebilir. LCOM bir sınıfın içindeki hiçbir ortak alanı paylaşmayan method toplamından , en az bir ortak alanı paylaşan method toplamının farkı ile bulunur.Bulunan değer 0’dan küçükse 0 kabul edilir.

C1 sınıfının M1, M2..., Mn şeklinde n tane methodu olsun . {Ii} kümesinin Mi sınıfının kullandığı sınıf değişkenleri olduğunu farzedelim .Bu şekilde her method için bir küme olduğunu fazedelim.

P değeri kesişimleri boş olan kümelerin sayısı ( P = { (Ii,Ij) | Ii Ç Ij = Æ } ) ve Q’yu kesişimleri boş olmıyan kümelerin sayısı ( Q = { (Ii,Ij) | Ii Ç Ij _ Æ }) olarak kabul edelim.Eğer tüm küme kesişimleri boş ise P değerini 0 kabul edelim.

Bu durumda LCOM = |P| - |Q| olarak kabul edilir.Eğer sonuç negatif ise LCOM = 0 olarak kabul edilir.

Örneğin M1 , M2 ve M3 methodları bulunan bir sınıfı ele alalım. M1’in kullandığı sınıf değişkenleri kümesi {I1} = {a,b,c,d,e} , M2 methodunun kümesi {I2} = {a,b,e} ve M3 methodunun kümesi {I3} = {x,y,z}olsun . Bu durumda {I1} Ç {I2} kesişimi boş olmıyan , ancak {I1} Ç {I3} ve {I2} Ç {I3} boş kümeler verir.Bu durumda

P = 2

Q = 1

ve LCOM = P – Q = 1 olarak bulunur.

· Methodların uyumsuzsuzluğu sınıfın iyi kapsulleme (encapsulation) sunamadığının göstergesidir

· Uyumsuzluğu yüksek sınıfların iki ya da daha fazla alt sınıfa bölünmeleri gözden geçirilmelidir

· Methodlar arası farklılık , sınıf dizaylarındaki çatlakların bulunmasında yardımcı olur

· Uyumsuzluk karmaşıklığı arttırır ve geliştirme sırasında hata yapılma ihtimalini arttırır

LCOM değeri sınıfın method sayısına bağlı olarak değişir.LCOM değerinin alabileceği sınır değer sınıfın method sayısıdır.Ekli grafikte sınıfların LCOM / NOM değerlerine göre dağılımı gösterilmiştir.

Paket Temelli Metrikler

Nesne yönelimli programlamada bir başka temel birim de paket kavramıdır.Sınıflar boşlukta yaşan kavramlar değildir.Her sınıf belli bir pakete üye olmak zorundadır.Paket kavramı sayesinde sistemin temel yapı taşları belirlenebilir , sistem yapılandırılabilir.Sınıflar paketlere gelişi güzel atılamazlar.Paketlemede nesne yönelimli dizayn prensipler sıkı sıkıya uyulması gereklidir.Bu bölümde ele alınan metrikler paket dizaynının kalitesini ölçmeye yönelik olarak hazırlanan metriklerdir.

Kararsızlık (Instability)

Durağanlık yazılımda , değişiklik sıklığı ile ilgili bir kavramdır.Bir paket ne kadar az değişiklik görüyorsa o kadar durağandır demektir.Durağanlığı sağlıyan unsurlar içeriğin karmaşıklığı , büyüklüğü , sağlam yapılmış olması vb. sebepler olabilir .Ancak nesne yönelimli dizayn içerisinde paketin durağan olmasını gerektiren en önemli unsur pakete olan bağımlılık sayısıdır. Bir başka deyişle pakete ne kadar bağımlılık var ise paket o kadar durağan olmalıdır.

Kararsızlık bir paketin ne kadar kararsız ya da durağan olduğunu gösteren metriktir.Şu şekilde formulize edilebilir :

Ca = İç Eşleme ( Afferent Couplings )

Ce = Dış Eşleme ( Efferent Couplings )

I Kararsızlık (Instability) . I = Ce / (Ca + Ce)

İç Eşleme ( Afferent Couplings - Ca) bir paket içindeki sınıflara bağlı olan paketin dışındaki sınıf sayısıdır.

Dış Eşleme ( Efferent Couplings - Ce) , bir paket dışındaki Class ’lara bağlı olan paketin içindeki Class sayısıdır.

Karasızlık metriği 0 ile 1 arası bir değer alır. 0 tamamen durağan bir paketi (ya da sınıfın) gösterirken değer 1’e doğru yaklaştıkça paketin kararsızlığı artıyor demektir.

Soyutluk (Abstractness)

Bu metrik ölçümü yapılan paketin ne kadar soyut bir yapıda olduğunu gösterir. Durağan soyutluk prensibi ( Stable Abstractions Principle - SAP) ile yakından ilişkilidir. Bu prensip durağan olması gereken paketlerin soyut yapıda olmasını söyler.Şu şekilde formulüze edilebilir :

Nc Paket içindeki sınıf sayısı.(Soyut sınıflar da dahil)

Na Paket içindeki soyut sınıf sayısı (arayüzler , soyut sınıflar vb)

A Soyutluk (Abstractness.) : A = Na / Nc

Bu metrik de kararsızlık metriği gibi 0 ile 1 arası bir değer alır .0 tamamen somut bir paketi gösterirken 1’e doğru yaklaştıkça paketin soyutluğu artıyor demektir.

Kararsızlık – Soyutluk Grafiği

Durağan Soyutluk Prensibine ( Stable Abstractions Principle - SAP) göre bir paket ne kadar durağan ise o kadar soyut olmalıdır.Paketin kararsızlık ve soyutluk değerleri üzerinden bir grafik oluşturulduğunda bu prensip görsel bir şekilde anlaşılabilmektedir.SAP prensibine göre eğer bir paket durağan ise (karasızlık 0 durumu) soyutluk o kadar artmalıdır. (soyutluk 1 durumu) .

Üstteki grafikte SAP prensibine göre olması gereken ana çizgi görülmektedir.Ana çizginin dışında kalan bölgede bulunan paketler sıkıntılara yol açacaktır.

Uzaklık Metriği

Bu metrik , kararsızlık-soyutluk grafiğinde bahsedilen ana çizgiye göre paketin uzaklığı belirler.

D’ Normalize Uzaklık (Normalized Distance) D’ = | A+I –1|

Bu metriğin 0 çıkması paketin direk ana çizgi üzerinde olduğunu gösterir.1 çizgiden mümkün olan en büyük uzaklıktır.Metriğin değeri 0-1 arasıdır.

D Uzaklık (Distance) D = |A + I – 1|

----------------

Ö2

Bu metrik 0 - ~0,707 arası bir değer üretir.

Doğrusal Bağımlılık Prensibi Metriği (The Acyclic Dependency Principle Metric - ADP/ADPR)

Doğrusal bağımlılık prensibi paketler arasındaki ilişki yapısında çevrimlerin bulunmaması yani döngüsel bağımlılıklar olmamasını gerektiğini söyler.

Bu metrik genel olarak bakılan paket ve alt paketleri ile birlik ADP prensibine olan uyumu yüzde cinsinden gösterir.

Ndp Paketler arası toplam Bağımlılık Sayısı (alt paketler dahil)

Ndac Paketler arası toplam doğrusal bağımlılık sayısı (alt paketler dahil)

ADP = (Ndac / Ndp ) * 100

ADP’ye tam uyumluluk önemlidir.Dolayısıyla bu metriğin %100 çıkması gereklidir.

Bağımlılığın Çevrimi Prensibi Metriği (The Dependency Inversion Principle Metric - DIP)

Soyut eşleme (abstract coupling) olarak da adlandırılan bu prensip kısaca bileşenler arası eşlemelerin (ya da bağımlılıkların) somut sınıflar üzerinden değil soyut sınıflar üzerinden yapılması gerektiğini söyler. DIP bir sınıf dizayn prensibi olduğu halde paket yapısı ölçümlemelerinin içinde de bir metrik olarak kullanılabilir.Bu metrik % cinsinden alınır.

Nddp Paket içindeki sınıflar arası toplam bağımlılık sayısı (alt paketler dahil)

Nddac Paket içindeki somut sınıflardan soyut sınıflara toplam bağımlılık sayısı (alt paketler dahil)

DIP = (Nddac / Nddp ) * 100

Normal şartlarda bu metriğin vereceği değerlerin yorumu , bakış açısına göre değişir.Ancak genel beklenti uygulama özel paketlerde değerin düşük çıkması daha altyapıya yönelik paketlerde ise değerin yüksek çıkmasıdır. Değerin %100 çıkması tüm bağımlılıkların soyut sınıflara doğru kurulduğunu gösterir.

Kapsulleme Prensibi Metriği ( The Encapsulation Principle Metric - EP)

İyi kurulmuş moduler bir yapıda ve kapsulleme prensibine uygun yapılarda paket içeriğinin gerçekleştirme detayları dış dünyaya kapalıdır.Bu metriğin yorumu incelenen pakete bağlı olsa da paketin kalitesi hakkında bir fikir verebilir.Metriğin değeri paketin kapsullenme derecesinin yüzde cinsinden ifadesidir.

Ncc Pakette Dışarıya kapalı sınıf sayısı

Nc Paketteki toplam sınıf sayısı

EP = ( Ncc / Nc ) * 100

Bu metrik paket kalitesi hakkında yorum yapmak için kullanılabilir ancak olması gereken değeri üzerinde bir tavsiye verilemez.Paketin yapısına göre yorum yapılmalıdır.

Sınırlı Boyut Prensibi Metriği ( The Limited Size Principle Metric LSP )

LSP prensibine göre bir paketin içindeki alt paket ve üst seviye sınıf sayısı belli bir boyutu aşmamalıdır.

Nmx Proje için belirlenmiş paket sınırı sayısı (genellikle 10-15 arası)

Ncp Paket içindeki alt paket ve üst seviye sınıf sayısı

LSP = (Ncp / Nmx ) * 100

Bu metriğin değerinin % 100 çıkması sınır değerine ulaşıldığını gösterir.100’ün üzerindeki değerler paket için aşırı yüklemeyi ifade eder.

Kaynakça

McCabe, T.J., "A Complexity Measure", IEEE Transactions on Software Engineering, vol. SE-2, pp. 308-320, 1976.
Booch, G., Object Oriented Design with Applications, Redwood City, CA: Benjamin/Cummings, 1991.
Karl E. Wiegers , “A Software Metrics Primer” Software Development Magazine , July 1999
Dr. Linda H. Rosenberg , “Applying and Interpreting Object Oriented Metrics “ , Software Assurance Technology Center (SATC) at NASA
“Software Quality Metrics for Object Oriented System Environments “ , Software Assurance Technology Center (SATC) at NASA , SATC-TR-95-1001
San Diego State University “Metrics “ Lesson Notes
Edward V. Berard , “Metrics for Object-Oriented Software Engineering “ , The Object Agency Inc. Web Site
Edwin Hautus ,” Improving Java Software Through Package Structure Analysis “ , Compuware Europe

Nesne Yönelimli Yazılımda Temel Kavramlar

2011-04-18T15:36:00.004+03:00

Selamlar,
İlgilenenler için faydalı olabileceği düşüncesiyle eski yazılarımdan bazı hazır içerikleri blog'umda yayınlayacağım. Umarım ilginizi çeker.

Esen Kalın.

Nesne yönelimli programlama 80’li yıllarda C++ ile popüler olan bir kavramdır.Sunduğu yeniden kullanım , kolay anlaşılırlık , kolay adaptasyon vb. özelikleri ile dikkat çekmiştir.Günümüzde yazılım geliştiricilerin çoğu bu disiplin ile yazılım geliştirmektedir.

Nesne yönelimli programlamada karşımıza çıkan en temel kavram sınıf (class) kavramıdır.Nesne yönelimli programlama bize gerçek dünyaya daha yakın bir programlama imkanı sunar.Gerçek dünyada biz nasıl etrafımızdaki tüm nesneleri özellikleri ve davranışları ile tanımlıyorsak , nesne yönelimli programlamada da aynı şekilde tanımlamaktayız. Örneğin yazı yazdığımız kalemi cinsi , boyu , rengi gibi özellikleri ile tanımlarız.Bunun yanı sıra kalem kağıt üzerinde yazı yazma davranışı sergiler.

Sınıf aynı özellik , nitelik , davranış ve anlamı taşıyan nesnelerin kalıbıdır diyebiliriz.Sizin mavi renkli yazan dolmakaleminiz de , kurşun kaleminiz de sonuçta kalem sınıfının birer örneğidir.Birbirlerinden farklı nitelikler taşısalar da ortak özellik (attributes) ve davranışlar (behaviours) ile tanımlanmaktadırlar.Kalem sınıfı şu şekilde tanımlanabilir :

Sınıfların özellikleri dilin doğal değişken tiplerinden oluşabileceği gibi başka sınıflardan da oluşabilir.Örneğin kalem kutusu diye bir sınıf tanımlansa muhtemelen özellikleri içerisine sahip olduğu kalemlerin de yani kalem sınıfının da konması gerekecektir.Bu durumda kalem kutusu sınıfı aynı zamanda kalem sınıfı ile ortaklık (association) kurmuş olarak adlandırılır.Bu ilişki “kalem kutusu kalemlere sahiptir” şeklinde okunabilir.

Bu ilişkiye sahiplik (has a) ilişkisi denir.Eğer bir nesnedeki her zaman bir diğerini de etkiliyorsa ya da var olmak için diğerine ihtiyaç duyuyorsa o zaman burada bir bağımlılık (dependency) ilişkisi vardır. Örneğin departman ile çalışanlar arasında ki ilişki gibi.Çalışanları olmıyan bir departman hiçbir zaman var olamaz.

Sınıfın yaratılan bir örneğine (instance) ise nesne (object) diyoruz.Bu durumda mavi renkli yazan dolmakaleminiz , kalem sınıfının bir örneği (instance) olan bir nesne (object) olur.

Nesne yönelimli programlamada nesneler birbirlerinin fonksiyonlarını kullanmazlar.Bunun yerine birbirleriyle mesajlar (messages) aracılığıyla haberleşirler.Görünüşte fonksiyonel yapıyla benzeşse de kavramsal olarak tamamen farklıdır.Sınıflar bir fonksiyonlar topluluğu değildir.Sınıf belli bir kavramın bilgisayar dilinde somutlaştırılmış halidir.Nesnelerin birbirlerine mesaj göndermesi sundukları methodlar (methods) üzerinden parametreler aracılığıyla (Örn. Kalem sınıfındaki yaz methodu) olur. Methodlar sınıfın dışarıya sunduğu arabirim oldukları gibi (her method dışa açık değildir) davranışlarında gerçekleştirildiği birimlerdir.

Burada daha fazla ilerlemeden nesne yönelimli programlamanın dört temel ilkesi üzerinde durmak faydalı olacaktır.Bu ilkeler :

Soyutlama (Abstraction)
Kapsulleme (Encapsulation)
Kalıtım (Inheritence)
Polimorfizm (Polymorphizm)

olarak anılırlar.

Soyutlama (Abstraction)

Sınıfların belli kavramların bilgisayar dilinde somutlaştırılmış hali olduğundan bahsetmiştik. Kavramların özelliklerinin ve davranışlarının tanımlanmasına biz soyutlama diyoruz.Bir başka deyişle soyutlama , bir sınıfın , sınıf olmasını sağlıyan şeylerin tanımlanmasıdır diyebiliriz.Örneğin araba ve gemi her ikisi de birer taşıttırlar .Ancak belli özellikleri ile birbirlerinden ayrılırlar. Örneğin araba sınıfını tekerlek sayısı , ağırlığı , hızı , motor gücü , kaç kapılı olduğu vb. özellikleri ile yürümesi , hızlanması , durması vb. davranışları ile tanımlayabiliriz.

Sınıfın belli bir kavramı temsil etmesinin yanı sıra kavram karmaşası da yaratmaması gerekir.Her sınıf kavramsal olarak bir düşünceye isabet etmelidir.Örneğin bir yolcu uçağı ile bir savaş uçağı birbirlerine çok benzeştikleri halde ayrı sınıflardır ve bunu belirtecek şekilde tanımlanmalıdırlar.Kavramsal olarak bir düşünceyi temsil eden ve karmaşıklık yaratmayan sınıflar uyumlu ( cohesive ) sınıflar olarak anılırlar. Programlamanın belki de en önemli ilkesi düşüncenin basit tutulmasıdır.Uyumluluk (cohesion) bu ilkenin nesne yönelimli programlamada adlandırılmasıdır denilebilir.

Kapsulleme (Encapsulation)

Niteliklerin ve davranışların sınıflarda bir arada bulunmasına kapsulleme denir.Bir başka deyişle kavram nitelikleri ve davranışları tanımlanarak – ya da soyutlanarak - bir sınıf içerisinde kapsullenir. Kapsulleme aynı zamanda sınıfın hangi niteliklerinin ve davranışlarının dışarıya sunulup sunulmıyacağını da belirler.Sınıfın tüm nitelik ve methodları dış dünyaya açık olmak zorunda değildir.Yine basit olma ilkesinden hareketle , gereksiz method ve niteliklerin dışarıya açılması kafa karıştırıcı ve gereksiz bir eylem olacaktır.Örneğin bir insan sınıfı tanımlarken muhtemelen karaciğerinin büyüklüğü bizi hiç ilgilendirmemektedir.Ancak bu sınıfın böyle bir özelliği vardır ve sınıfın kendi iç çalışması için gereklidir.Bilgilerin bu şekilde gizlenmesine bilgi saklama (information hiding) denir.

Sınıfın nitelikleri ve methodları public , protected , private , package (friend) gibi terimlerle dışa olan açıklığı , görünürlüğü belirlenir.

Public : Dışa açık ve herkez tarafından erişebilen elemanlardır
Protected : Dış erişime kapalı sınıf içinde ve alt sınıflarda da kullanılabilen elemanlardır
Private : Sadece o sınıf içinde kullanılabilen , alt sınıflar tarafından da kullanılamıyan elemanlardır
Package (friend) : Ait olunan paket içindeki sınıflar tarafından kullanılabilen , paket dışı erişime kapalı elemanlardır

Kalıtım (Inheritance)

Nesne yönelimli programlamada sınıflar birbirlerinden türiyebilirler.Alt sınıflar (sub classes) türedikleri üst sınıfın (super class) tüm özellik ve davranışları aynen alırlar.Bu özelliğe kalıtım (inheritance) özelliği denir.Bunun anlamı , alt sınıfların üst sınıfların nitelik ve methodlarını sanki kendi üzerlerinde kodlanmış gibi kullanabilmeleridir.Örneğin araba ve gemi her ikiside birer taşıttır.Taşıtların ortak özellikleri kapasitesi , gitmesi , durması , hızlanması vb. sayılabilir.Aslında hem gemi hem araba için bunlar aynıdır ve ortak bir üst sınıfta toplanabilirler.Kalıtım özelliği aynı kodun yeniden kullanımı için sunulan çok güzel bir yöntemdir.

Bazı dillerde bir sınıf sadece bir başka sınıftan kalıtım alabilirken (türiyebilirken) bazı dillerde bu birden fazla sınıftan olabilir.Bu özelliğe çoklu kalıtım (multi inheritence) denir.

Araba ve taşıt örneğindeki ilişki “araba bir taşıttır” (“is a “ ilişkisi) olarak okunur ve bu ilişkiye genelleştirme de ( generalization ) denir.Alt sınıflar aynı zamanda üst sınıf özellikleri de taşıdıklarından yazılım içinde sanki üst sınıfmış gibi ya da onun yerine de kullanılabilirler.

Nesne yönelimli programlamada bazı üst sınıflar bazı methodlarını alt sınıflarda tamamlanmak üzere sadece tanımlayarak (sadece methodu belirterek ) bırakabilirler . Bu tip sınıflara soyut (abstract) sınıf adı verilir.Tüm methodları sadece tanımlanmış ama kodlanmamış sınıflara arabirim (interface) adı verilir. Tüm kodlaması tamamlanmış sınıflar ise somut (concrete) sınıf olarak adlandırılır.Somut bir sınıfın soyut bir sınıftan türediği ilişki türüne gerçekleştirme (realization) adı verilir.Bu tarz üst sınıflar alt sınıflara yeniden kullanılabilir davranışlar verilemediği ancak davranış kalıbının belirlenmek istediği durumlarda kullanışlıdır.

Yeniden kullanılabilirliği arttırmak için sınıflar dizayn edilirken kavramlar genelden özele doğru kategorize edilmeli ve gerekli üst sınıflar ortaya çıkarılmalıdır.Bazı durumlarda kendi başına anlam ifade etmeyen hatta tamamen soyut üst sınıfların ortaya çıkması tamamen doğal birşey olarak algılanmalıdır.

Polimorfizm (Polymorphizm)

Alt sınıflar üst sınıflarda belirlenmiş davranışlara aynı tepkileri vermek zorunda değildir. Yine taşıt örneğinden yola çıkarsak gitmek davranışı araba ve gemi için farklı şekillerde olur.Biri yürüken diğeri yüzer ancak sonuçta her ikisi de gitme eylemini gerçekleştiriyordur.Alt sınıfların bu şekilde farklılıklar gösterebilmesi özelliğine polimorfizm denir.Bu özellik pratikte üst sınıf tarafından sunulan methodların üzerinin yazılması (method overriding) ile olur.Alt sınıf methodu kendine göre değiştirerek ezer.Ancak methoddan beklenen sonucun tipi değiştirilemez.

Alt sınıflar doğaları gereği üst sınıflara göre ek özelliklerle ve veya davranışlar göstermek zorundadırlar.

Nesneler işlevlerini yerine getirmek için başka nesnelere ihtiyaç duyabilir. Nesneler arasında ister diğer nesnenin bir nitelik olarak tanımlanması olsun , ister bir mesajlaşma şekilde olsun , kurulan ilişkiler (kalıtım ilişkisi dışında) eşleme ( coupling ) olarak adlandırılır.Bir nesneye çalışmak için ihtiyaç duyduğu sınıf (nesne değil) sayısı kadar eşleme yapılmış olur.Eşleme kavramı sınıfın karmaşıklığı ile direk alakalıdır.Sonuçta nesne ile diğer sınıflar ile ne kadar çok eşleme yapılmış ise çalışma sisteminin çözülmesi o kadar karmaşık olacaktır.Bu kavram prensipleri ve metrikleri açıklarken oldukça sık karşımıza çıkacaktır.

Nesneler dünyasında sıklıkla karşımıza çıkacak bir kavramda durum (state) kavramıdır.Nesnenin niteliklerinin belli bir andaki durumu özellikle nesnenin yaşam döngüsünün tariflemesinde önemlidir.Bazı sınıfların yapısı ve anlaşılması son derece karmaşık olabilir.Nesneler çeşitli durumlarında farklı davranışlar da gösterebilirler.Nesnenin bir durumdan diğerine geçmesine durum değişikliği (state change) denir.Bu durum değişikliğine ise olaylar (events) sebep olurlar.(Örneğin bazı tip mesajların gönderilmesi gibi) .Durumlar , olaylar ve durum geçişleri bize kavramsal olarak bir kolaylık sağlar.Olay yönelimli (event driven) programlama yapısıda bunun üzerine kurulmuş bir yapıdır.

Yazılımda Kalite Kavramı

2011-04-15T16:56:00.006+03:00

Yazılım geliştirme sektöründe verimlilik kavramı , kaliteden ödün vermeden hızlı yazılım geliştirebilmek olarak tanımlanmaktadır.”Kaliteli” , beklentileri yakalayan hatta aşan ürün ya da hizmetler kullanılan bir terimdir.Kaliteli bir yazılımdan beklentiler genel olarak şu şekilde özetlenebilir :

Doğruluk (Correctness)

Verilen görevlerin tam olarak yerine getirilmesi olarak açıklanabilir.Bir yazılıma başlamadan önce beklentilerin tam olarak belirlenmesi gerekir.Yazılım ortaya çıktıktan sonra beklenen özellikler tam olarak sağlanmalıdır.

Dayanıklılık (Robustness)

Beklenmedik nedenlerden dolayı programın çalışması kesilmemeli , yanlış işlemler yapılmamalıdır.Sistem iyi yönde de olsa kendinden beklenmeyen işler yapmamalıdır.Sistemin programcı hataları yüzünden kesintiye uğramaması için gerekli önlemler alınmalıdır.

Genişleyebilme (Extendibility)

İleri aşamalarda verilen görevlerin değiştirilmesi ya da yenilerinin eklenmesi kolay olmalıdır.

Tekrar kullanım (Reusability)

Yazılımın ya da yazılımın parçalarının başka yazılımlar içerisinde kullanılabilmelidir .

Uygunluk (Compability)

Endüstride kabul görmüş standardların (veri yapıları , mesaj yapıları ,kullanıcı yüzü vb) yazılım içerisinde uygulanması.

Standardlaştırma (Standardization)

Sistemin içerisinde kullanılacak standardların belirlenerek , tüm yazılımda buna uyulması.Standardlaştırma kaynak kodunda kullanılacak isimlendirmeden , kullanıcı ön yüzlerinin renklere kadar geniş bir kapsamda uygulanmalıdır.

Etkin Kaynak Kullanımı (Efficiency)

Bir yazılım çalıştığı ortamdaki tüm ekipmanları en iyi şekilde kullanmalıdır.Kaynakları eksik kullanmamak , gereğinden fazla kullanmamak , ortamın çalışmasına en az şekilde etkilememek olarak sayılabilir.

Taşınabilirlik (Portability)

Bir yazılımın geliştirildiği ortamlardan farklı ortamlara da taşınarak çalışması olarak özetlenebilir.Yazılım iki şekilde taşınabilir :

1. Kaynak Taşımalı : Yazılımın kaynak kodunun farklı bir ortama taşınıp tekrar derlenerek çalıştırılabilmesi

2. Hedef Taşımalı : Yazılımın icra edilebilir dosyalarının taşınarak tekrar çalıştırılabilmesi

Kontrol Edilebilirlik (Verifiability)

Bir yazılımın hatalı durumlar ile karşılaşması durumunda kullanıcıya ve programcıya hata hakkında yeterli bilgi verebilmesi
Yazılımın çalışma şekli hakkında bilgi verebilmesi (çalışma süreleri , çalışma zamanları vb)
Yazılımın kod akışının gereğinde izlenebiliyor olması

Bütünlük (Integrity)

İstenmeyen erişimler ve değiştirmeler karşısında program , veri , doküman gibi elemanların korunması .Hata durumlarında tutarsızlıklar olmasına izin verilmemesi.Örneğin programın bilgisi dışında bir dosyanın silinmesi halinde programın bunu anlayıp rapor etmesi.

Kolay Kullanım (Easy of use)

Yazılım ürününü kullanan kişinin ürünü kolayca öğrenmesi , sonuçlarını yorumlayabilmesi , hatalarını düzelterek işlerini fazla bir zahmete girmeden yapabilmesi.

Beraber Çalışma (Interoperability)

Yazılımın ihtiyaç duyduğu diğer yazılımları çağırabilmesi veya bir yazılım tarafından çağırılabilmesi özelliğidir.Bu durumda iki yazılım ardarda çalışma yanı sıra veri alışverişinde de bulunabilmelidirler.

Dokümantasyon (Documentation)

Yazılımı meydana getiren öğeler (standardlar , mimari , dizayn , algoritmalar vb) açık ve anlaşılır bir şekilde dokümante edilmiş olmalıdır.

Güvenilirlik (Reliability)

Hazırlanan uygulamaların yüksek erişilebilirlik oranlarına sahip olması gereklidir. Sistem örneğin 7X24 erişilebilir olmalıdır.Yazılım tamamen ya da kısmen çökse bile kısa zaman içerisinde ayağa kaldırılabilmelidir.

Ölçeklenebilirlik (Scalability)

Hazırlanan yazılımlar ileride olabilecek kapasite artışlarını (örneğin kullanıcı sayısının artışı) karşılayabilir ve çözümü adreslemiş olmalıdır.

Hata Engelleme

Yazılım kullanıcıların hata yapmasını engellemelidir.Örneğin işlemler yerine getirilmeden kullanıcıdan doğrulama istenmesi , işlem sonucunun önceden bildirilmesi vb.

Son Kullanıcı Desteği (End User Support)

Yazılım son kullanıcıya kullanım hakkında yeterli yardımı sunabilmelidir.Ayrıca kolay kurulabilir olması ve yazılımın sürümü hakkında yeterli bilgi vermesi de gereklidir.

Güvenlik (Security)

Yazılım yetkili olmayan kullanıcıların işlem yapmasını ve verilere erişimini engellemeli , kritik verilerin şifreli şekilde saklamalıdır.

Tüm bu özelliklerin sağlanabilmesi pek çok disiplinin yazılım süreçleri boyunca uygulanması ile mümkün olabilir.Bu yazıda dizayn üzerinde ağırlıklı olarak durulmuşsa da bu tek başına kaliteli yazılım için yeterli değildir.Doğru dizaynın yanı sıra isteklerin toplanması , analizi , değişikliklerin ele alınması , risk kontrolünün yapılması , sınamaların yapılması , dokümantasyonun yapılması vs gibi pek çok disiplin doğru şekilde uygulanmalıdır.

Sağlıcakla Kalın.

Mimari Stillerin Birleştirilebilirliği Hakkında

2011-04-15T16:53:00.004+03:00

BT dünyası hakkında zihnimdeki serbest çağrışımları paylaşacağım güncenin ilk yazısına sebep olan şey bir meslektaşımda rastladığım zihin karışıklığı oldu. Benzer durumlarla daha önce de karşılaştığımdan ve futbol taraftarı gibi bir yazılım mimarisi taraftarı olmayı hiç de doğru bulmadığımdan bu yazıyı ele almaya karar verdim.
     Genel bir prensip olarak, yazılım mimari stilleri karşılıklı olarak birbirlerini dışlamıyorlar ise birleştirilebilirler (Zannediyorum bu özellik bilgi teknolojileri dışındaki çeşitli alanlar için de geçerlidir). Bir başka deyişle hazırlanan bir sistem içerisinde farklı mimari stilleri aynı anda bir arada uygulanabilir. Üstelik bu sıklıkla arzu edilen de bir durumdur. Örneğin bir uygulama ilişkisel veri mimarisi, nesne yönelimli mimari ve model yönelimli mimariyi bir arada rahatlıkla bulundurabilir.

   Hal böyleyken sıklıkla karşılaştırma yapma ya da bir mimari stili öldürme meraklıklarına rastlıyorum. Bu yazıyı yazmamdaki sebep bu kişilere çatma isteğim değil elbette, özellikle IT dünyasına yeni adım atan kişilerin gereksiz zihinsel karmaşalara kapılmalarını önlemeleri için küçük bir tavsiye vermek. Nesne yönelimli yazılımı öldürüp yerine servis odaklı mimari geçirmeye çalışanlar, ya da servis odaklı mimariyi işe yaramaz ilan edip yerine kaynak odaklı mimari geçirmeye çalışanlar sıklıkla herhangi bir yazılım departmanında karşınıza çıkabilir ve daha da kötüsü sizide saflarına çekebilirler.Benim durumumda iseniz de size gereksiz ikna seansları yaşatabilirler.

Bu tarz karşılaştırmalara dalmadan evvel size önerim karşılaştırılan stillerin gerçekten birbirini dışlayan ve birbirini ikame eden stiller olup olmadığını iyice düşünmenizdir. Eğer böyle değil ise sadece birinin tarafı olmak yerine her iki stilin de en iyi yönlerinin birleştirilebilirliği konusunda kafa yormak daha iyi olacaktır.

Aksine karşılaştırmalar görseniz de varsayımsal bir yazılım sisteminin şu stilleri bir arada taşıması pekala da mümkündür: Object Oriented, Aspect Oriented, Process Driven, Event Driven, Resource Oriented, Web Oriented, Service Oriented.

   Sağlıcakla Kalın

BT Güncem

Şirketiniz İçin SOA

Servis Nedir?

Servis Odaklı Dizayn Prensipleri

İş Yaşamında Servis Odaklılık

Servis Tipleri

SOA Sadece Servisler Dünyasından mı İbaret?

Stratejik Bir Yaklaşım Olarak SOA

Sonuç

Nesne Yönelimli Yazılımda Dizayn Prensipleri

Sınıf Dizayn Prensipleri

Açık Kapalıdır Prensibi (The Open Closed Principle - OCP)

Liskov’un Yerine Koyma Prensibi(The Liskov Substitution Principle - LSP )

Bağımlılığın Çevrimi Prensibi ( The Dependency Inversion Principle - DIP )

Arabirimin Ayrılması Prensibi ( The Interface Segregation Principle – ISP )

Birleşik Yeniden Kullanım Prensibi ( The Composite Reuse Principle - CRP )

En Az Bilgi Prensibi ( The Principle of Least Knowledge - PLK)

Tek Sorumluluk Prensibi ( The Single Responsibilty Principle - SRP)

Paket Dizayn Prensipleri

Paket Uyumluluk Prensipleri ( Package Cohesion Principles )

Sürümün Yeniden Kullanım Eşitliği Prensibi ( The Release Reuse Equivalence Principle - REP)

Genel Toplanma Prensibi ( The Common Closure Principle - CCP)

Genel Yeniden Kullanım Prensibi ( The Common Reuse Principle - CRP)

Paket Eşleme Prensipleri (Package Coupling Principles )

Doğrusal Bağımlılık Prensibi ( The Acyclic Dependency Principle - ADP)

Durağan Bağımlılıklar Prensibi ( The Stable Dependencies Principle - SDP)

Durağan Soyutluk Prensibi ( Stable Abstractions Principle - SAP)

Diğer Dizayn Prensipleri

Kapsülleme Prensibi ( The Encapsulation Principle - EP )

Sınırlı Boyut Prensibi ( The Limited Size Principle - LSP)

Kaynakça

Yazılım Mimarisi (Software Arhitecture)

Altsistemler (Subsystems)

Katmanlar (Layers)

Bölümler (Partititons)

Bileşenler (Components)

İlişkisel Veri Tabanı Dizaynı

Yayinci No

Kurumsal SOA

Yazılım Ölçümleme

Geleneksel Metrikler

Kod Büyüklüğü (Lines Of Code LOC)

Yorum Oranı (Comment Percentage - CP)

Döngüsel Karmaşıklık (Cyclomatic Complexity -CC)

Nesne Yönelimli Metrikler

Sınıf Temelli Metrikler

Sınıf Method Sayısı (Number Of Methods per Class -NOM)

Chidamber ve Kemerer Metrikleri

1. Sınıf Başına Ağırlıklı Method (Weighted Methods per Class -WMC)

2. Kalıtım Ağacının Derinliği (Depth of Inheritance Tree - DIT)

3. Alt Sınıf Sayısı ( Number of Children - NOC)

4. Nesneler Arası Eşleme (Coupling Between Object Classes - CBO)

5. Sınıf Yanıt Sayısı (Response for a Class - RFC)

6. Uyumsuzluk (Lack of Cohesion - LCOM)

Paket Temelli Metrikler

Kararsızlık (Instability)

Soyutluk (Abstractness)

Uzaklık Metriği

Doğrusal Bağımlılık Prensibi Metriği (The Acyclic Dependency Principle Metric - ADP/ADPR)

Bağımlılığın Çevrimi Prensibi Metriği (The Dependency Inversion Principle Metric - DIP)

Kapsulleme Prensibi Metriği ( The Encapsulation Principle Metric - EP)

Sınırlı Boyut Prensibi Metriği ( The Limited Size Principle Metric LSP )

Kaynakça

Nesne Yönelimli Yazılımda Temel Kavramlar

Yazılımda Kalite Kavramı

Mimari Stillerin Birleştirilebilirliği Hakkında