Yazılım Mimarileri

Yazılım mimarileri, yazılımın inşası için gerekli olan yazılımın tüm yapılarının iskeletini oluşturan ve bunu üst seviyeden görebilmek için ihtiyaç duyulan planlardır.

• Sistemin nasıl davranması gerektiğini en üst düzeyde açıklayan sistematik bir yoldur.
• Yazılımın fonksiyonlarını, tüm bileşenlerini, kısıtlamaları, yazılıma ait modüllerin özellikleri ve bunlar arasındaki ilişkilerin ne olduğunu açıklar.
• Sistemin nasıl yapıldığıyla değil de nasıl tasarlanması yazılım mimarisiyle ilgilidir.

Yazılım mimarisinde soyutlanan iki düzey mevcuttur. Bunlardan biri sistemin kendi mimarisi yani sistemin bileşenlerini mimari açıdan gösteren düzey, diğeri ise genel olarak mimari; diğer sistemleri, programları ve bu programların bileşenlerini içeren kurumsal sistemlerin mimarisidir. Yani, farklı şirketler tarafından sahip olunan ve yönetilen dış sistemlerdir.

Mimari Model (Architectural Pattern)

Mimari model , belirli bir bağlamda yazılım mimarisinde yaygın olarak ortaya çıkan bir soruna yönelik genel, yeniden kullanılabilir bir çözümdür. Mimari modeller ayrıca, farklı ortamlarda testi yapılmış iyi tasarım deneyimlerinin stilize edilmiş halidir. Yazılım sistemlerinde, yazılım ilişkisini ve oluşumunu göstermeye “Mimari Model (Architectural Pattern)” adı verilir.

Mimari modeller, sorumlulukları, rolleri bunların ilişkilerini belirleyen kurallar ve yor haritaları ile ilişkilendirme yapılarını sağlayan ve yeniden kullanılabilir bir çözüm olarak da düşünülebilir. Farklı ortamlarda test edilen mimari modeller, yüksek kaliteli ve verimli bir yazılım sistemi sunmak, mimari sistemlerin anlaşılmasına dayalı olarak maliyeti tahmin etmek ve ayrıca bir projenin zaman çizelgesini hızlandırmaya olanak sağlar.

• Uygulamanın genel özelliklerini tanımlar,
• Ürünün işlevselliğini arttırır,
• Uygulama oluşturma süreçlerinin verimliliğini ver üretkenliğini arttırır.

Mimari modeller, hangi durumda kullanılabilir olduğunu ya da hangi durumda kullanılamaz olduğuna dair bilgileri içermelidir. Modeller, grafik ve tablo vb. araçlar ile açıklanabilir. Belli başlı yaygın kullanılan yazılım mimarileri mevcuttur. Bu yazıda Katmanlı Mimari, Boru & Filtre Yazılım Mimarisi, İstemci-Sunucu Yazılım Mimarisi, Depo Yazılım Mimari, Bileşen Tabanlı Mimari, MVC Yazılım Mimarisi ve detaylı olarak SOA’yı ele alacağım.

Katmanlı Mimari (Layered Architecture)

Katmanlı mimari model, bağızsız ve ayrı çalışma mantığı için en çok kullanılan mimarilerdendir. Multier ya da n-tier olarak da bilinir. Farklı soyutlama düzeylerinde ayrılabilecek alt işlevsellik içeren uygulamalar için kullanılabilir. Katmanlı Mimaride, her katmanda farklı bir işlev mevcuttur.

Katmanlar sırasıyla, presentation layer, bussiness layer, remote service layer, persistence layer ve database layerdir. Her katman kendi üstündeki katmana için çalışır. Katmanlar, tek yönlü iletişim halindedir; her katman kendi hizmeti için altındaki katman tarafından sunulan hizmete bağlıdır.

Bu mimarinin avantajlarından biri her bir işlevsellik farklı bir katman olarak ayarlanması ve ayarlanan bu katmanların ayrı ayrı kullanılmasıdır. Ayrıca, stilde diğer katmanlardaki herhangi bir değişiklik diğer katmanları etkilemez. Dolayısıyla bu durum, düzenlemeyi de kolaylaştırır. Bir katmanın arayüzünün değişmesi sadece ona bitişik katmanı etkileyecektir. Arayüz değişmediği takdirde, bir katman eşdeğer başka bir katmanla değiştirilebilir.

Normal bir şekilde katmanlar arasında sağlam bir ayrım yapmak genellikle zordur ve üst düzey bir katmanın hemen altındaki katmandan ziyade alt düzey katmanlarla doğrudan etkileşime de girebilir. Her katmanda işlenirken bir hizmet talebinin birden çok düzeyde yorumlanması nedeniyle performans sorunları yaratabilir.

Hangi Durumlarda Kullanılmalıdır?

Katmanlı mimari, savunma sanayi projelerinde sıklıkla kullanılır. Mevcut sistemlerin üzerine yeni özellikler eklenirse, yeni işlevsellik inşa edilirse ve her katmanın sorumluluğu ayrı bir ekibe verilirse ve ayrıca çok seviyeli güvenlik gerekiyorsa Katmanlı Mimari kalıbı kullanılmalıdır.

Katmanlı mimari tasarım için iyi bir başlangıçtır. Ancak unutulmamalıdır ki, katman sayısı arttıkça sistemde performans sorunları ve verimsizlik de artabilir. Katmanlar kendi halinde uygulamalar olarak tasarladığımızda tek parça yapılara dönüştürebiliriz. Bu durumda her bir katmanı da kendi içinde alt servislere böldüğümüzde bu sorunu da çözebiliriz. Dolayısıyla, şuan günümüzde en popüler mimari kalıp olan mikro servis yapısını da bu şekilde katmanlı tasarlanması tavsiye edilir. Özetleyecek olursak, katmanlı mimarinin kolay geliştirilebilmesi ve test edilebilmesi açısından avantajlıdır ancak performans, genişleme ve çeviklik açısından dezavantajlıdır diyebiliriz.

Boru & Filtre Yazılım Mimarisi (Pipe & Filter Architecture)

Boru ve Filtre mimarisi modeli, sıralı işleme yapan modüler ayrıştırması sayesinde çok güçlü ve sağlam bir mimaridir. Bu mimaride, ayrı ayrı filtreleme bileşenleri mevcuttur. Filtreler arasında da yerel bağlantı vardır ve bu bağlantılara “Pipe” adı verilir. Her bileşne ait bir input ve output mevcuttur. Her filtre kendisine gelen veriyi işler ve sıradaki filtreye aktarır. Filtreler sayesinde veriler zenginleşebilir, detaylar gizlenebilir başka bir şekile dönüştürülebilir..

Verilerin geçirilmesi bitişik filtreler arasındaki bağlayıcılar sayesinde gerçekleştirilir. Tüm filtrelerin aynı anda işlemesi sayesinde farklı iş parçacıkları aynı anda da çalıştırılabilmesini sağlar. Bu işlemlerin sonunda veri hedefine (sink) aktarılmış olur. Boru & Filtre Yazılım Mimarisi eşzamanlı bir şekilde çalışır. Yani, filtreler bir diğerine bağlı olmadığı süre boyunca aynı anda çalışabilmeleri sayesinde veriler daha hızlı bir şekilde işlenir. En büyük avantajlarından biri, aynı anda eşzamanlı çalışan yeni filtre ve bağlayıcıların kolayca eklenebilmesi ve hızlı bir şekilde büyütülebilmesidir. Ek olarak, bağımsız filtreler yeniden kullanmak oldukça kolaydır. Bu mimarnin bir gelişmiş şeklide “Lambda Mimarisi” olarak adlandırılır. Lambda mimarisinde, kaynaktaki veri iki farklı hattan ilerler. Reel zamanlı ihtiyacı karşılamak üzere hız katmanında veri işlenirken daha detaylı analiz sağlayan yığıt katmanından da işlenir.

Hangi Durumlarda Kullanılmalıdır?

Öncelikle, filtreler arasında fazla etkileşime ihtiyaç duyan ve kullanıcılara anında dönüt gerektiren sistemler geliştiriyorsanız boru & filtre yazılım mimari bunun için uygun değildir. Bu mimari, birden fazla birbirinden ayrılabilen büyük süreçler için idealdir. En iyi örnek UNIX Shell olarak verilebilir. Görüntü ve ses işleme veya derleyiciler bu mimari modeli için uygun sistemlerdir.

İstemci-Sunucu (Client-Server) Yazılım Mimari

Bu mimaride İstemci (Client) ve Sunucu (Server) olmak üzere iki ana bileşen mevcuttur. İstemci, isteği yapan sunucuda isteği karşılar, başka bir deyişle servisi sağlar. İstemci ve Sunucu bileşenleri farklı katmanlarda olsalar da aynı altyapı üzerinde de yer alabilirler. İstemci, sunucuya istek atar. Sunucu bu gelen isteği kabul ettiğinde istemciyle belirli bir protokol üzerinden bir bağlantı sağlar. Burada, sunucular “stateful” ve “stateless” olabilir. Sunucunun istemciden gelen istekleri tuttuğu kayda “oturum” adı verilir.

İstemci-Sunucu mimarisinin en büyük avantajı dağıtık bir mimari olmasıdır. Sunucu tarafından sağlanan bir servis tüm istemciler tarafından kullanılabilir. Bu servis için tüm servislerin sağlanmasına gerek yoktur. Yani burada bahsettiğim şey servislerin bağımsız ve birbirlerinden ayrı olmasıdır.

Dezavantajından değinecek olursak, sistem ağa bağlı olduğundan ağ üzerindeki hıza bağlı olarak performans problemleri de ortaya çıkabilir. Bir diğer dezavantaj ise, eğer sunucular farklı şirketler tarafından yönetiliyorsa, yönetim sorunu ortaya çıkabilir.

Hangi Durumlarda Kullanılmalıdır?

Sunucular arasında paylaşılan veritabanının farklı lokasyonlardan farklı istemci sistemlerinden erişilmesi gerekiyorsa ve sistem üzerindeki yük değişken ise kullanılabilir.

Depo (Repository) Yazılım Mimari

Sistemdeki tüm verilerin tüm sistem bileşenlerinin erişebileceği merkezi bir havuzda yönetilir. Bileşenler, direkt olarak etkileşime girmeyip, bu havuz vasıtasıyla iletişime geçerler. Depo Yazılım Mimari, merkezi bir veri yapısından ve merkezi veri yapısı ile çalışan bağımsız bileşenlerden oluşur. Birbirinden bağımsız bu bileşenler ortak depoya veri ekleyebilir ve buradan veri çekebilirler. Bir bileşen tarafından yapılan herhangi bir değişiklik, tüm bileşenlerde de değişebilir. 

Bu sistemin bir avantajı yedekleme sisteminin kolay olabilmesidir. Çünkü tüm veriler tek bir veritabanında tutulduğu için tek bir veritabanının yedeğini almak oldukça kolaydır. Dezavantajından bahwsedersek, veritabanındaki herhangi bir sorun, diğer tüm sistemi de etkiler.

Hangi Durumlarda Kullanılmalıdır?

Veritabanı yönetim sistemlerinde kullanılabilir. Yani, uzun süre saklanması gereken büyük boyutlu verilerin üretildiği bir sistemde kullanılabilir.

Bileşen Tabanlı Mimari

Bileşen tabanlı mimari, küçük bileşenler ve bu bileşenleri toplayan bileşen yöneticisiden oluşur. Bileşen yöneticisi, çalışma zamanında kendisine tanımlanan bileşenleri yönetir. Bileşenlerin, genelde tanımlı standart arayüzü yoktur. Eclipse ve Jira araçları örnek verilebilir.

Model-View-Controller (MVC) Yazılım Mimarisi

Node.js ve .Net kullanan arkadaşların mutlaka karşılaştıkları bu mimariyi açıklayalım. MVC, ilk olarak 1970’lerde tanımlandı. MVC’nin temel amacı iş mantığı ve verileri sunum detaylarından ayırmak ve bağımsız değişebilmelerini sağlamaktır. Bu mimari, uygulama ile sunum kısmını ayrı katmak olarak ele alır. Sunum kısmında controller ve view olarak ayrılır. Temel olarak “Model”, “View” ve “Controller” olmak üzere üç bileşenden oluşur.

Model: Uygulama (Application Logic) kısmı ile ilgilenir. MVC’nin üç bileşeninden en düşük seviyelisidir. Bu kısımda temel fonksiyonlar yer alır ve verilerin korunmasından da sorumludur. Dolayısıyla kaynak yönetimi “model” olarak adlandırılır.

View: Burada, uygulamanın kullanıcılarla etkileşimde bulunduğu önyüzü hazırlamak için kullanılır. Modeldeki verilerin görünümü etkileşim sağlayabilmek için uygun forma, Yani UI olarak ifade ettiğimiz önyüze dönüştürülür. Örneğin, Node.js’deki HTML sayfalarının EJS olarak kullanılıp sisteme entegre edilmesi bu aşamada gerçekleştirilir.

Controller: Bu bileşen, “View” ile “Model” arasında köprü bağı kurar. Veriler üzerindeki işlemleri yönetir. Örneğin sayfaların yönlendirilmesi, kullanıcıların yapmak istediği istekleri yönetir.

Yukarıdaki bu üç bileşen birbirinden bağımsız olarak tasarlanabilir ve geliştirilebilir. Bu sebeple kullanımı kolay bir mimaridir.

SOA – Service Oriented Architecture

SOA, Türkçe karşılığı ile Servis Odaklı Mimari; servislerin bir ağ üzerinden bir iletişim protokolü aracılığıyla uygulama bileşenleri tarafından diğer bileşenlere sağlandığı bir yazılım tasarımı tarzıdır. Bu mimaride , bir dizi hizmet birbiriyle iki yoldan biriyle iletişim kurar: veri aktarımı yoluyla ya da bir etkinliği koordine eden iki veya daha fazla hizmet aracılığıyla. 

Kurumsal uygulamlarda bulunan farklı işlevleri karşılamak için hızla birleştirilebilen ve tekrardan kullanılabilen, birlikte çalıştırılabilir standartlara dayalı servis organizasyonudur. SOA, standart arayüzler ve protokeller kullanır, farklı platformların sorunsuz entegre edilebildiği dağıtık sistem mimarisidir. Farklı bileşenleri, ortak bir arabirim ve kanal aracılığıyla iletişim kurması ve entegre etmek için kullanılır. Kullanılan bu kanala “Enterprise Service Bus” adı verilir.

Service Provider (Servis Sağlayıcı): Servise erişimi barındıran platformdur.

Service Requestor (Servis Kullanıcısı): Servisle Etkileşimi arayan ve başlatan uygulamadır.

Service Registry (Servis Kaydı): Servis sağlayıcıların açıklamalarını yayınladığı, servis tanımlarının aranabilir bir kaydıdır.

Publish (Yayınla): Servisin erişilebilir ve talep edenin bulunabilmesi için bir servis açıklamasının yayınlaması gereklidir.

Find (Bul): Bu işlemde kullanıcı direkt olarak servis bilgilerini elde eder ya da servisi registery üzerinden sorgular. Bulma işlemi tasarım zamanında uygulama geliştirme için servis arayüzün tanımlarını almak için yapılır.

Bind (Bağla): Son durumda servis çağrılmalıdır. Binding işleminde, servise talep bulunan uygulama iletişim kurmak ve ilgili servisi çağırmak için açıklamalardaki bağlama ayrıntılarını kullanarak çalışma zamanında servisle bir iletişim kurar.

SOA’nın Bileşenleri

Application Front-end (Uygulama Önyüzü): Veriyi son kullanıcılara aktaran bileşendir. Web uygulaması ya da GUI’ye sahip herhangi bir uygulama örnek verilebilir.

Service (Servis): Üst düzey bir iş konseptini kapsayan bileşendir.

Contract (Anlaşma): Servislerle ilgili işlemler (amaç, işlevsellik, kısıtlama, kullanım) için tanımlama sağlayan bileşendir.

Interface (Arayüz): Bir servisin sağladığı fonksiyonun bunu kullanacak istemcilerin bağlanıp kullanılabilmesini sağlayan bileşendir. Servisin metodu olabildiği gibi komut satırı da olabilir.

Implementation (Uygulama): Servisin uygulaması, gerekli iş mantığı ve uygun verileri sağlar. Program, konfigürasyon, veritabanı vb. yapıları içerir.

Service Repository (Servis Deposu): Servislerin erişim haklarını, sahip olduğu nitelikler vb. özelliklerini kaydeder.

Service Bus (Servis Veri Yolu): Uygulamaları ve servisleri entegre etmek için kullanılan esnek bir altyapıdır. Mesajlar ve servisler arasındaki etkileşimi yönlendirir. İş olaylarını yönetir ve iletir.

SOA odaklı mimari tasarlanırken bazı ilkeler mevcuttur. Bu ilkeler SOA’nın karakteristiğidir diyebiliriz. Bu ilkeler, “Standardized Service Contracts”, “Loose Coupling”, “Service Abstraction”, “Service Reusability”, “Service Autonomy”, “Service Statelessness“, “Service Discoverability” ve “Service Composability” olmak üzere 8 tanedir.