“Yazılım mı tasarlarız, yoksa yazılım mimarisini mi?” şeklinde yukarıdaki soruyu geliştirdiğimiz yazılımlar için de sorabiliriz. Hem yazılımın kendini, hem de yazılım mimarisini  tasarlamayı aynı kelime ile tanımladığımız için bu kavramlarda karışıyor. “Tasarım”…

“Software Design” ve “Software Architecture Design” iki farklı kavram aslında. Bu iki kavramın karıştırılıyor olması, mimari kavramların kaybolmasına neden oluyor ne yazık ki. Bundan dolayı “Tasarım”(Design) ve “Mimari”(Architecture) kavramlarının arasındaki sınırı çok iyi anlamamız gerekmekte. Tüm mimari yaklaşımlar aslında bir tasarımdır. Ama bu tasarım, “Yazılım Tasarımı”(Software Design) daki tasarım değil. Mimari olarak yaklaştığımız zaman, “tasarım” kavramı çok daha yukarıdan bakmamızı gerektiren bir kelime olarak karşımıza çıkıyor. Bir yazılım ya da sistemdeki bileşenlerin nasıl organize olduğu ve ilişkilendirildiği, o sisteme ya da yazılıma “Mimari” açıdan yaklaşımı gösterir. Bu bileşenlerin nasıl sınıflandırıldığı ve ayrıştığı ise “Tasarımı” olarak açıklanabilir. Biraz daha basite indirgememiz gerekirse, yazılım geliştirirken bileşenlerimizi  “sınıf”(class)’lara ayırmamız, bu “sınıf”lar arasında ilişkileri belirlememiz “tasarım” kavramının konusu. Ama bileşenlerimizin(component) nasıl ilişkilendirileceği de “mimari” kavramının konusu.

Açıkcası kendi geliştirdiğim yazılımlarda, bu iki kavramın ayrımını fark ediyor olmak geliştirme sürecini daha sağlıklı hale getiriyor.Bir yazılım geliştirmeden önce hepimizin yapmış olduğu bir tasarım mutlaka vardır. İşte bu tasarım süreci  mimari tasarıma denk geliyor aslında. Ve yazılım geliştirme sürecinde herkesinde bildiği gibi çok önemli bir yer kaplıyor. Bu süreçte dikkat edilmesi gereken bir çok önemli nokta var.Bunlardan bence en önemlilerini kendimce anlatmaya çalışacağım;

• Sınırlar: Tasarım sürecinde, geliştirmemiz gereken yazılımın ya da sistemin ihtiyaçları ve neden gerekli olduklarını kesinlikle unutmamak lazım. Ve ihtiyaçtan fazlasını düşünmememiz lazım. Açıkcası bunu sürekli yaşıyorum. İster istemez yazılımın olabildiğince geniş bir kapsamı olması, ya da “genişletilebilir” kalite özelliğinin hem tasarım hemde geliştirme sürecinde öne çıkması kötü tasarımlara yol açıyor. İş gereksinimleri dışında, tasarımı karmaşıklaştıracak etkenleri tasarıma sokmamak ve ihtiyaçlarımız doğrultusunda sınırlarımızı aşmamak lazım.
• Bileşenlerin Ayrılması: Tasarımı yaparken, bir birinden farklı tüm fonksiyonel özellikleri belli bileşenler olarak ayırmak tasarımın karmaşıklığını önleyecektir, ayrıca ihtiyaçların gerçekten karşılanabiliyor olmasının gözlemlenmesine ve bileşenlerin tek başlarına ne işe yaradıklarını da anlamaya yardımcı olacaktır.Literatürde “Separation of Concerns” olarak yer alan bu kavram, geliştirme sürecindeki tasarım kalıpları ile ne kadar önemli olduğunu zaten belli edecektir.  Dolayısıyla geliştirme sürecinde sonradan fark etmek yerine, başlangıçta bu yaklaşıma göre yapılacak tasarımlar faydalı olacaktır.
• Bileşim(Composition) ve Kalıtım(Inheritance): Bu iki kavramın çok iyi anlaşılıyor olması gerekmekte. Çünkü geliştirilecek sistemin ya da yazılımın bileşenleri üzerinde bu iki kavramın çok büyük etkisi olacaktır. İhtiyaca göre bu iki yaklaşım doğru çizilmelidir.”Kalıtım”(Inheritance) bileşenler üzerinde bağımlılığı artıracağından, hangi bileşenlerin bir birleri ile alakalı olacağı ilişkisinin çok iyi tanımlanması gerekmekte. Öte yandan “Bileşim”(Composition) bileşen kavramını daha netleştirecektir.
• Katmanlar(Layers): Geliştirilen sistem ya da yazılım da, bileşenler arasındaki ilişikileri görmek ve yönetmek adına sistemi ya da yazılımı katmanlara ayırmak tasarımı kolaylaştıracak ve temelini güçlendirecektir. Bu şekilde katmanlara ayırmak sistemdeki akışın yolunuda görmenize yardımcı olacaktır.

Mimari tasarımı yaparken bu tarz şeylere dikkat ediyor olmak, cidden bazı şeyleri çok daha net ortaya çıkarıyor ve sağlıklı bir geliştirme sürecinin ilk ışıklarını gösteriyor. En azından kendi tecrübelerime dayanarak bunu söyleyebilirim.Kendi tecrübelerim ve bilgilerim dahilinde “Mimari Tasarım” ve “Yazılım Tasarımı” arasındaki farkı anlatmaya çalıştım. Hatta biraz da “Mimari Tasarım”a daldım…Umarım faydalı olmuştur.İlerleyen zamanlarda bu konular hakkında daha çok yazıyor olacağım. Her türlü eleştiriniz ve düşüncenizi lütfen paylaşmaktan çekinmeyin. Bu kavramlar böyle böyle ortaya çıkıyor ve gelişiyor…Haydi görüşmek üzere…

Yazılım kavramında mimari yaklaşım önemli bir unsur. Ne kadar bunu biliyor olsakta,ya da bildiğimizi sansakta uygulamaya gelince zaman zaman afallıyoruz. Hatta çok afallıyoruz…Çünkü yazılım kavramında mimariyi tam olarak tanımlayamıyoruz ya bilmiyoruz.

Yazılımda mimari yaklaşımlar, yazılım mimarisi, mimari modeller, mimari tasarım bu olayların içerisinde olduğumdan beri en çok ilgili çeken konular. Genellikle çözülmesi gereken olaylara, sebeplerini, oluşum süreçlerini ve nasıl çözülürse ne olur gibi yaklaşımlarla yaklaştığım için sanırım bundan dolayı da yazılım mimarisi kavramına olan ilgim arttı;üniversite de bu konu ile ilgili aldığım derslerin de etkisi yok değil.
Peki nedir bu yazılımda ki mimari ya da yazılım mimarisi?

Yazılım mimarisi en basit ve temel şekilde, bir sistemi oluşturan yapılar ve bu yapıların birbiri ile olan ilişkileri olarak tanımlanabilir. Ancak çok ucu açık ve geniş bir tanım olduğundan biraz daha derinlere inip kurcalamakta fayda var. Bu noktada L. Bass, P. Clements, ve R.Kazman beraber yazdığı “Software Architecture in Practice“(bu kitabı şiddetle tavsiye ederim.Mutlaka okunmalı.) kitabından bir alıntı yaparak başlamak istiyorum.(-ki bir çok kaynakta da zaten bu alıntı vardır.) Bu tanımlama bence yazılım mimarisinin en açık ve anlamlı tanımı.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.

Kendimce biraz daha anlayabileceğim şekilde yorumlamak açıkcası bu kavramları daha iyi anlamama yardımcı oluyor.Bu bağlamda bende “Yazılım mimarisi: bir yazılımın(sistemin); teknik tüm ihtiyaçlarını, iş kuralları dahilinde, operasyonel tüm ihtiyaçlarını belli kalite gereksinimlerini de göz önüne alarak ortaya çıkmış yapı ya da yapıların ilişkiler halinde bulunduğu bütünüdür” diyebilirim. Bu yapıları ele alırken aralarındaki ilişki(ler) ise mimarinin temelini ve modelini oluşturur. Ve bu noktada bu ilişkilerin ne yazık ki göz ardı edildiğini ve mimari yaklaşımdan uzaklaşmamıza sebep olduğunu düşünüyorum. Ne demek istediğimi ileride netleştireceğim.
Peki cidden gerekli mi?Olmazsa ne olur?

Aslına bakarsanız gerekliliğinin sorgulanabileceğini bir kavram olduğuna inanmıyorum yazılım mimarilerinin. Yani yukarıda bahsettiğim tanımlamaları düşünmeden bile bir yazılım ortaya çıkarmaya çalışabilir ve hatta başarılı olabiliriz. “Yapmadan” kelimesi yerine “Düşünmeden” kelimesini seçmemin önemli bir noktası var. Bir yazılım geliştirirken her ne kadar mimari açıdan fazla kurcalamasakta, yazılımın var oluş sebepleri, mimari yaklaşım içerisinde olduğundan ortaya çıkacak yazılım sistemlerinin mimarisi yok diyemeyiz. Kısaca geliştirilen her türlü yazılımın bir mimarisi zaten doğası gereği var. Bu noktada yazılım mimarisinin gerekliliğinden çok, neden ihtiyaç duyduğumuzu düşünürsek daha anlamlı sonuçlara varabiliriz.
İyi…Peki o zaman, neden ihtiyaç duyuyoruz?

Bir yazılım geliştirmeye neden ihtiyaç duyuyorsak aynı sebepten. 🙂 Biliyorum biraz karışık oldu ama aslında temelinde bu yatıyor. Belli ihtiyaçlarımızdan dolayı gereksinim duyduğumuz yazılımları geliştirirken, bu ihtiyaçları elimizden geldiğince yazılım için anlamlaştırmamız(soyutlaştırmamız) ve kesinleştirmemiz gerekmekte. İhtiyaçlarımızı, yazılım açısından daha belirgin hale getirmek için mimariye bu noktada ihtiyaç duyuyoruz. Bu noktada mimari modeller ve mimari sitiller zaten karşımıza çıkıyor. İhtiyaçlarımızdan farklı olarak da operasyonel veya teknik anlamda bazı kavramları da daha net görmek adına mimari yaklaşıma ihtiyaç duyuyoruz. Aşağıdaki gibi maddelendirip özetlemek biraz daha yardımcı olacaktır.

• Sistemimizi oluşturan yapıları daha net görmek için ve hangi yapılara ihtiyaç var belirlemek için
• Sistemi oluşturan yapılar arasındaki ilişkileri sağlıklı kurabilmek için
• Sistem ihtiyaçlarını karşılamak için
• Sistem maliyetini düşürmek için
• Oluşturabileceğimiz sistemi başka sistemler ile ilişkilendirebilmek için
• Sistemi paylaştırebilmek için

Uzun zamandır takıntılı olduğum bu konularda, kendi düşüncelerim ve tecrübelerimi paylaşmaya çalışacağım. Öğrendiğim, takip ettiğim tüm kaynakları da buradan paylaşacağım. Ve lütfen bu konulardaki tüm düşüncelerinizi sizde paylaşıyor olun, ya da zaten paylaşım içindeyseniz beni de dahil edin :).Açıkcası bu tarz şeylere dikkat ettiğimizi ve bu açılardan yaklaşarak geliştirme yaptığımızı pek sanmıyorum bundan dolayı da bu tarz kavramların bu şekilde gelişeceğine inanıyorum. Şimdilik bu kadar…