Sayfalar

Şirketiniz İçin SOA



               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

                                                                                                                                                    
    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