Genel olarak yazılım mimarisi aşağıdaki unsurlarla ilgili önemli / kayda değer  kararları içine alır:

• Sistemin oluştuğu yapısal elemanlar  neler ?
• Bu yapısal unsurlar birbirlerine nasıl ilişkilendirilmiş? Bunlar arasındaki arayüzlerin seçimi
• Bu yapısal elemanların davranışları  neler  ve aralarında nasıl bir  işbirliğini var?
• Bu yapısal elemanlar daha büyük alt  sistemler oluşturmak için nasıl bir araya getirilecek?
• Sistemin  oluşturulmasına rehberlik eden mimari sitil/çerçeve (architectural style/frame) nedir?

Ve  bunlara ek olarak -en önemlisi belki-
Yukarıdaki sorulara verdiğimi cevapların arkasında yatan, ona rehberlik eden  prensipler ve gerekçeler neler?
Yazılım mimarisi bir bakıma daha sonra değişmesi maliyetli / külfetli olan her türlü karararı kapsar.O yüzden alınan kararların gerekçelendirilmesi önemlidir.

Mimari ve Tasarım

Mimariye ait her şey aynı zamanda tasarıma aittir. Fakat tersi doğru değildir: her yazılım tasarımı unsuru mimariye dahil değildir.Yazılım mimarisi  sistem açısından  gerek yapısal gerekse davranışşal ve dinamik  açıdan önemli/ kayda değer  kararları  içerir ve bunların performans, güvenilirlik, maliyet, esneklik  vb. unsurlara etkisi üzerinde odaklanır.

Neden Mimariye İhtiyacımız Var

Yazılım sistemleri bizim içinde yaşadığımız 3 boyutlu bir dünyada yer alan fiziksel unsurlar değillerdir.Büyük ve  karmaşık yazılım sistemleri, paydaşların ortak bir vizyona yönelik olarak geliştirme yapabilmeleri için mimariye ihtiyaç duyar.

neden?

 

• Sistemi anlamak için : Yazılımın geliştirilebilmesi için sistemin ilgili paydaşlar tarafından anlaşılması gerekmektedir. Modern yazılım sistemlerinin  anlaşılması çeşitli nedenlerden dolayı  kayda değer bir karmaşıklık göstermektedir.Bunun  nedeni  sistemin karmaşık davranışlar içermesi, karmaşık ortamlarda çalışması, teknolojik olarak karmaşık olması vb olabilir. Bu nedenle iyi bir mimari tanımlama , geliştiricilerin, yöneticilerin, müşterilerin ve diğer paydaşların sistemin geliştirilmesine iştirak etmeleri için ne yapacaklarını yeterli seviyede gerektiği kadar detaylandırarak, anlamalarını kolaylaştırmalıdır.
• Sistemin geliştirilmesini organize etmek için:  Proje ekipleri  büyüdükçe, geliştiricilerin çalışmalarını koordine etmek için harcanacak ek iletişim zamanıda o ölçüde artmaktadır.Yine bu ekiplerin  coğrafi olarak dağıtık durumunda bulunması bu zamanı  attırıcı bir rol oynayacaktır.Yazılım mimarı  geliştirilecek sistemi  iyi tanımlanmış arayüzleri olan daha küçük alt sistemlere böler, her bir alt sistemin sorumluluğunu  kişi veya gruplara dağıtarak, farklı alt istemler üzerinde çalışan bu grupların çalışmalarını koordinate etmek için harcanacak ek zamanını(iletişim için) bu şekilde  azaltabilir. Kararlı arayüzler, arayüzün konuşturduğu her iki tarafın  kolayca değişebilmesine olanak verecektir.Yine iyi bir mimari test çalışmalarını hızlandırıp, entegrasyona ait riskleri bir an önce  bertaraf etmek için  çabucak işe koyulmamızı sağlar.
• Yeniden kullanılabilirliği arttırmak için:  İyi bir mimari  geliştiricilerin yeniden kullanılabilir için, doğru bileşenleri belirlemelerini ve  bunları az maliyetle nerelerde bulabilecekleri bilmelerini  kolaylaştırır
• Sistemin zamanla genişletilmesi/büyütülmesi için: Başarılı sistemler büyüme eğilimindedir.( ek özellikler, yeni sürümler vb.) Bu durumlarda mevcut sistemde çok büyük ölçekli (dramatic) bir etki oluşturmadan sisteme ek özelliklerin kazandırılması gerekmektedir. İyi bir mimari sistem zarif bir şekilde büyüyebilmesine olanak tanır.

Mimari Analiz

Mimari Analiz  sistem "mimarisini"  önemli  bir şekilde etkileyecek gereksinimler üzerine odaklanmış  gereksinim analizi sürecinin özel bir hali  olarak görülebilir.Başka bir deyişle mimari analiz  sisteme ait fonksiyonel olmayan gereksinimlerin( örneğin security), sisteme ait fonksiyonel gereksinimler bağlamında belirlenmesi ve bunların yerine getirilebilmesi için çözümün sunulmasıdır.
Özetle mimari analiz

• Mimariyi etkileyebilecek faktörlerin belirlenmesi
• Bunların önceliklerinin ve değişkenliklerinin anlaşılması
• Bunlara ait çözümlerin sunulabilmesi

için yapılır.

Mimariyi Etkileyebilecek Faktörlerin Belirlenmesi

Mimari analizin en önemli amaçlarından/hedeflerinden birisi çeşitli faktörlerin/etkenlerin mimariye etkisini,
önceliği ve değişebilirliğini anlamaktır.
Bu etkiyi basit tablolar üzerinde ifade edip inceleyebilirsiniz.

Kalite Senaryoları
Kaliteye ilişkin gereksinimleri mimari etken /faktör analizi aşamasında tanımlarken, kalite senaryolarının ( quality scenarious) kullanılması tavsiye edilmektedir.
Çünkü kalite senaryoları ilgili faktöre ait ölçülebilir(veya en azından gözlemlenebilir) bir tepki /cevap  tanımlamakta ve bu nedenle doğrulanabilmektedirler.

Kalite senaryoları = < etki/uyarı> <ölçülebilir tepki >  şeklindeki kısa  ifadelerdir.


Örneğin:
"Sistem kullanıcı dostu olacak" şeklindeki muğlak bir ifade yerine
"Kullanıcı sistem x’de herhangi bir işlem yapmak istediğinde, sistem kullanıcının ilgili işlemi en fazla 3
fare tıklaması ile yapabilmesini sağlamalıdır."
"Sistem  hızlı çalışmalıdır"şeklindeki muğlak bir ifade yerine
"Bankacılık Sisteminden müşteriye ait hesap bilgilrei istendiğinde, bu bilgiler  sistemde işlem yükü
“ortalama” seviyede olduğunda, “çoğunlukla” 3 saniye içinde alınabilmelidir."
Not: Dikkat ederseniz ikinci örnekte “ortalama” ve “çoğunlukla” sözcükleri ilgili yazılım mimari açısından
daha detaylandırılması, araştırılması gereken terimler olarak hala ortada durmaktadır.
Kalite senaryoları test edilebilir olmadıkça gerçekten geçerli senaryolar olarak görülemezler.

Yani kalite senaryoları tam ve net olarak ifade edilmelidirler.

Uyarı:
Eğer kalite senaryoları gerçekleştirmiyecekseniz, bunları yazmanızından bir anlamı yoktur. Bu senaryoları yazarken gerçekçi olun:

• Mevcut kaynaklar, zaman ve bütçe çerçevesinde bu senaryoyu gerçekleştirebilir misiniz?
• Bu senaryoların  kim, nasıl test edecek?
• Kimsenin  dikkate almayacağı, test etmiyeceği sofistike kalite senaryoları yazmanın hiçbir anlamı yoktur.
• Bunların yazılması kolay olmakla birlikte esas zorlu unsur bunların gerçekleştirilmesidir.

Mimari Kararların Kayıt Altına Alınması
Mimari analiz aşamasında alınan karaların, mevcut alternatif çözümlerin  vb. kayda değer unsurun kayıt altına alınmasında fayda vardır. Bu tür kayıtlara technical memos, issue cards veya architectural approach documents gibi farklı isimler verilebilmektedir. Bu kayıtların karmaşıklığı ve belgelenmesine ait formal unsurlar değişkenlikler göstermektedir. Bu belgelere ait şablondan daha önemli olan bunların

• Basit olarak tutulması
• Gelecekteki Muhatabı  sistem üzerinde değişiklik yapmak istediğinde ona yardımcı olacak- bilmesi gereken- bilgiyi kayıt altına almasıdır.

Çevik Süreçler ve Yazılım Mimarisi

Çevik süreçler temelde "mimari" merkezli bir geliştirmeye özel bir vurgu yapmazlar.Sistemin olması gerektiğinden daha esnek -farazi ileride olabilecek değişikliklere göre- ve daha karmaşık yapılmaması gerektiğine vurgu yapar.(Çünkü bunlar bir bakıma "israf" ).

Aynı şekilde Çevik süreçler tasarımın "evrimsel" olarak geliştirilmediği,salaş bir şekilde yeni sistem özelliklerin sisteme eklendiği, başlarda hızlı,maliyeti düşük olan ama sonlara doğru,oluşan "kod yığına" yeni bir özelliğin eklenmesinin zor olmasından dolayı "yavaşlayan" yöntemi de tavsiye etmez.

Kod Yığını: Değişken, metod, sınıf isimlendirmeleri anlamlı değil hatta yanıltıcı isimler taşıyor.Kod tekrarları çok fazla.Yazılımın akış kontrolünün anlaşılması ve takip edilmesi zor. Kod farklı programcıların yeni özellik ekleme, hata düzeltme ve benzeri çalışmaları altında "yamalı bohçoya" dönmüş. Kimsenin kod üzerinde "entellektüel" bir hakimiyeti yok. Bu tür sistemlerin kısa bir süre sonra "yeni baştan" yazılması gerekir.

XP örneğin bu iki uç arasındaki orta yolu  Test-Güdümlü Geliştirme (TDD) ve Sürekli Yeniden Yapılandırma (Refactoring) ile bulmaya çalışır.

http://blog.briandicroce.com/ http://blog.briandicroce.com/

Test Güdümlü Gelistirme (Test-Driven Development) :İstenilen yeni özelliklere veya iyilestirmelere ait test durumlarının önce, daha sonrada bu test durumlarını geçecek/gerçeklestirecek “üretim” kodunun yazıldığı bir yazılım gelistirmetekniğidir. Testin temel amacı, yazdığınız kod parçasının beklediğiniz davranısı yaptığı doğrulamakla beraber, ayrıca yazdığınız birim testler kodun ne yapması gerektiğine dair bir belgeleme sağlamaktır. Bunun yanında gerçek gelistirme kodundan önce testlerin bulunması yapılan her bir değisikliliğin ilgili yazılım birimine yaptığı etkiye ait hızlı bir geri besleme sağlamaktadır.
TDD bir test tekniği değildir o nedenle ilgili yazılım birimini/parçasını kim yazıyorsa birim testlerde bizzat o kişi/gelistirici tarafından yazılır.

Refactoring : Sistemin daha iyi anlaşılması ,daha kolay değiştirilebilmesi ve yeni unsurların daha kolay eklenebilmesi için sistemin iç yapısında -sistemin dıştan görünen davranışı değiştirilmeden- yapılan değişiklikler.

Not: Koddaki hangi "kötü kokular" kodunuzu yeniden yapılandırmanız (refactoring) gerektiğine dair isaret verir?Genel bir sınıflandırma için bakınız: Industrial Logic --> Smells to Refactoring--> Quick Reference Guide http://www.industriallogic.com/papers/smellstorefactorings.pdf

Refactoring :Önce salaş bir şekilde yap sonra düzelt.Bu işi neden EN baştan "düzgün" yapmıyoruz?Bu da bir israf değil mi? Refactoring işleminin işe kattığı değer ne?

Her şeyi "baştan" en doğru şekilde yapabilseydik bu güzel olurdu.Ama öyle değil.Tasarım,kodlama faaliyetleri debundan istisna değil.Çevik süreçler basitçe bunu kabullenir: yazılım geliştirmeye "deneysel" bir süreç olarak bakar.

Eğer aşağıdaki çalışmaları  düzenli olarak yapmazsanız bunun size bir maliyeti olacaktır.

• Kod Tekrarlarını kaldırmak
• Kodu Basitleştirmek
• Kodun amacınI muhatabı için açık hale getirmek

Bu maliyet veya  başka bir tabirle Teknik Borç ödenmezse belirli bir süre sonra geliştirme hızınız çok yavaşlayacatır ve hatta bazı uç durumlarda sistemi sil baştan yazmanız gerekecektir. Borcu ödemeyip ödemek size kalmış...:-)

Bizce  TDD ve Refactoring tasarımınız iyileştirmek için son derece yararlı araçlar/pratikler  olmasına karşın tek başlarına işlevsel bir mimarinin oluşmasını sağlıyacak mekanizmalar değildir.

Çevik süreçler "baştan sona herşeyin" tasarlandığı tasarım  faaliyetlerini (mimari tasarımda dahil) salık vermemektedir.Fakat bu kodlamaya başlamadan önce ( veya sonralarında) mimari analiz/tasarım yapmayacağımız anlamı taşımamaktadır. [ Orta yol  var]Çevik süreçler bu analiz / tasarım çalışmalarının "kağıt" üzerinde uzun süreli olarak yapılmamasını, hemen kodlama ve test ile geçerliliklerinin işe yararlılıkların görülmesini salık vermektedir.Çevik süreçler açısından mimarinin işlevselliği kodlanıp testlerden geçmedikçe anlaşılamaz.Bu çalışma "KAĞIT" üzerinde yapılıp, doğrulanamaz, "rüştü ispatlanamaz".

Dolayısıyla mimari oluşturma faaliyetlerinizdeki bazı pratikleri çeşitli farklı medodolojilerden/yöntemlerden Örneğin RUP'tan hatta SEI tarafından oluşturulan ATAM'dan bile "yürütebilir" ve bunları "Çevik" bir bakış açısıyla uygulayabilirsiniz.Unutmamanız gereken kendinize şu soruları sormak:

• Bunu neden yapıyorum?
• Bunu yapmamın sürecime kattığı net değer, pratik fayda ne?

Bu sorulara makul ve mantıklı cevap  verebiliyorsanız her türlü pratik Çevikçinin Yitik Malıdır.[ Bize göre tabiki :-) ]


Hamiş: Bakmanızı tavsiye edeceğimiz kaynaklar
 

1. Hiç beklenmiyecek şekilde :-) Microsoft'un Yazılım Mimarisi ile kayda değer güzel çalışmaları var. [ Application Architecture Guide 2.0 ] Ücretsiz olarak http://www.codeplex.com/AppArchGuide  sayfasından indirebilirsiniz.
2. Peter Eeles tarafından yazılan hoş bir makale: Mimari açıdan kayda değer gereksinimleri bulmada kullanılabilecek  yöntemleri için güzel bir özet sunmuş  http://www.ibm.com/developerworks/rational/library/4706.html
3. Yazılımın bazen nasıl bir baş belası olabilceğini gösteren bir makale  BIG BALL OF MUD :-) Sizi bilmem ama ben "BIG BALL OF MUD"'u gördüm:-)  http://www.laputan.org/mud/mud.html
4. Kalite Senaryolarının tanımlanma biçimleri için Quality Attribute Workshops (QAWs), http://www.sei.cmu.edu/publications/documents/03.reports/03tr016.html
5. Refactoring ile ilgili ilginç bir tartışma için  http://www.infoq.com/news/2009/06/stop-and-refactor
6. Refactoring ve israf http://www.infoq.com/news/2007/12/refactoring-is-waste