Yazılım Mühendisliği

Mimari Tasarım

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

İçindekiler

• Mimari Tasarıma Giriş
• Mimari Tasarım Kararları
• Mimari Görünümler
• Mimari Desenler: MVC ve Katmanlı Mimari
• Mimari Desenler: Depo, İstemci-Sunucu, Boru ve Filtre
• Uygulama Mimarileri
• Dil İşleme Sistemleri
• Bölüm Özeti

Öğrenme kazanımları

Bu dersin sonunda:

• Yazılım mimarisinin ne olduğunu ve sistemin işlevsel olmayan özelliklerini neden belirlediğini açıklayabilecek,
• Mimari tasarım kararlarını ve performans, güvenlik, emniyet, erişilebilirlik, bakım kolaylığı ve ölçeklenebilirliğin mimariye etkisini tartışabilecek,
• Bir mimariyi 4+1 ve kavramsal görünümlerle anlatabilecek,
• MVC, katmanlı, depo, istemci-sunucu ve boru ve filtre desenlerini karşılaştırıp bir probleme uygun olanı seçebilecek,
• Hareket işleme, bilgi sistemi ve dil işleme uygulama mimarilerini tanıyıp bir sistemi bunlara göre değerlendirebileceksiniz.

Kazanımları okurken her birinin bölümün hangi kısmına karşılık geldiğini söyleyin: giriş, tasarım kararları, görünümler, desenler ve uygulama mimarileri. Ders sonunda bu listeye dönüp öğrencilerden her kazanım için bir örnek vermelerini isteyebilirsiniz.

Mimari Tasarıma Giriş

Bu bölümde mimari tasarımı ele alıyoruz: Bir yazılım sisteminin nasıl örgütleneceğini ve genel yapısının nasıl kurulacağını. Mimari tasarım, yazılım tasarım sürecinin ilk aşamasıdır ve gereksinim mühendisliği ile tasarım arasındaki kritik bağlantıdır.

Mimari tasarım nedir?

Mimari tasarım, sistemin ana yapısal bileşenlerini ve bunlar arasındaki ilişkileri belirler. Gereksinimlerden ayrıntılı tasarıma geçerken atılan ilk adımdır; ikisi arasındaki köprüdür.

Bu sürecin çıktısı bir mimari modeldir. Model, sistemin birbiriyle iletişim kuran bileşenlerden nasıl oluştuğunu anlatır.

Örnek: paketleme robotunun mimarisi

Kitaptaki örnekle başlayalım: farklı nesneleri paketleyebilen bir robotun kontrol sistemi. Görüntü sistemi, konveyör üzerindeki nesneleri seçer. Nesne tanıma sistemi nesnenin türünü belirler.

Kol denetleyici robot kolunu nesneye götürür; tutucu denetleyici nesneyi kavrar ve teslim konveyöründen alır.

Nesnenin türüne göre uygun paket seçilir, nesne paketlenir ve paketlenmiş nesne başka bir konveyöre bırakılır. Model, bu bileşenleri ve aralarındaki bağlantıları gösteriyor. Ayrıntı yok; sistemin nasıl örgütlendiğini bir bakışta anlatıyor.

Bu tür diyagramlara blok diyagramı denir. Her kutu bir bileşendir; kutu içindeki kutular alt bileşenleri gösterir; oklar veri ya da kontrol sinyallerinin hangi yönde aktığını anlatır.

Gereksinim ve mimari iç içedir

İdeal olan

Gereksinim belirtimi hiçbir tasarım bilgisi içermez; önce ne, sonra nasıl konuşulur.

Gerçekte olan

Ana bileşenler gereksinim aşamasında belirlenir. İşlev grupları büyük bileşenlerle eşleştirilir ve paydaşlarla bu ayrıştırma üzerinden konuşulur.

Çok küçük sistemler dışında, mimariye gereksinimler tamamlanmadan başlanır.

İdeal dünyada gereksinim belirtimi hiçbir tasarım bilgisi içermez. Bu, çok küçük sistemler dışında gerçekçi değildir. Pratikte ana mimari bileşenleri gereksinim aşamasında belirleriz, çünkü bu bileşenler sistemin üst düzey özelliklerini yansıtır. Sonra gereksinimleri paydaşlarla bu ayrıştırma üzerinden konuşuruz.

Çevik süreçlerde de mimari önce gelir

Çevik süreçlerde bile, işin başında genel bir sistem mimarisi tasarlamak gerektiği kabul edilir. Mimariyi artım artım geliştirmek genellikle iyi sonuç vermez.

Bir bileşeni değişikliklere göre yeniden düzenlemek görece kolaydır, çünkü değişiklik o bileşenle sınırlı kalır.

Mimariyi yeniden düzenlemek ise pahalıdır. Yeni mimariye uymak için bileşenlerin çoğunu değiştirmeniz gerekebilir.

Küçük ve büyük ölçekte mimari

Mimariyi iki soyutlama düzeyinde düşünebiliriz. Küçük ölçekte mimari, tek tek programların mimarisiyle ilgilenir: Bir programın bileşenlere nasıl ayrıldığı. Bu bölümün konusu çoğunlukla budur.

Büyük ölçekte mimari ise başka sistemleri, programları ve bileşenleri içeren karmaşık kurumsal sistemlerle ilgilenir. Bu sistemler farklı bilgisayarlara dağılmış olabilir; bilgisayarların sahibi ve yöneticisi farklı kuruluşlar olabilir. Bu düzey, dağıtık sistemler konusunda ayrıntılı ele alınır.

Mimari neden önemli?

Bireysel bileşenler, sistemin işlevsel gereksinimlerini gerçekleştirir: sistemin ne yaptığını.

Performans, sağlamlık, dağıtılabilirlik ve bakım kolaylığı gibi işlevsel olmayan özellikler üzerindeki baskın etki ise mimarinindir. Mimari açıdan önemli gereksinimler üzerine yapılan bir çalışma da bunu doğruladı: Mimariyi en çok etkileyen gereksinimler, işlevsel olmayan gereksinimlerdir.

Mimariyi açıkça tasarlamanın üç faydası

Paydaş iletişimi

Mimari, sistemin üst düzey bir sunumudur; farklı paydaşlar arasındaki tartışmanın odağı olur.

Sistem analizi

Mimariyi erkenden açık hâle getirmek analiz gerektirir: Sistem performans, güvenilirlik, bakım kolaylığı gibi kritik gereksinimleri karşılayabilecek mi?

Büyük ölçekli yeniden kullanım

Benzer gereksinimli sistemlerin mimarisi çoğu zaman aynıdır. Ürün hattı mimarileri aynı mimariyi bir dizi ilişkili sistemde kullanır.

Bass, Clements ve Kazman (2012)

Mimariyi açıkça tasarlamanın ve belgelemenin üç faydası vardır. Birincisi paydaş iletişimi: Mimari, farklı paydaşların üzerinde tartışabileceği üst düzey bir sunumdur. İkincisi sistem analizi: Mimari kararlar, sistemin performans ve güvenilirlik gibi kritik gereksinimleri karşılayıp karşılayamayacağını derinden etkiler; bunu erkenden düşünmeyi zorunlu kılar. Üçüncüsü büyük ölçekli yeniden kullanım: Benzer gereksinimli sistemlerin mimarisi çoğu zaman aynıdır. Ürün hatları, aynı mimariyi bir dizi ilişkili sistemde yeniden kullanır.

Blok diyagramların iki kullanımı

Tasarım üzerine tartışmak

Ayrıntıdan arınmış üst düzey bir görünüm. Paydaşlar sistemi bütün olarak tartışır; yöneticiler ana bileşenlere göre ekip ve plan kurar.

Tasarlanmış mimariyi belgelemek

Bileşenleri, arayüzlerini ve bağlantılarını gösteren eksiksiz bir model. Sistemi anlamayı ve evrimini kolaylaştırır.

Mimari modeller iki amaçla kullanılır. Birincisi tasarım üzerine tartışmaktır. Ayrıntıdan arınmış bir görünüm, paydaşların sistemi bütün olarak konuşmasını sağlar. Yöneticiler de ana bileşenleri görüp işi planlamaya başlayabilir. İkincisi tasarlanmış bir mimariyi belgelemektir. Burada amaç bileşenleri, arayüzlerini ve bağlantılarını gösteren eksiksiz bir modeldir; sistemi anlamayı ve geliştirmeyi kolaylaştırır.

Kutu ve çizgi tartışması

Eleştiri

Gayriresmî blok diyagramlar ne bileşenler arasındaki ilişkinin türünü ne de bileşenlerin dışa açık özelliklerini gösterir (Bass ve ark.).

Pratik

Sezgiseldir; alan uzmanları ve mühendisler birlikte tartışabilir, yöneticiler planlamada kullanır. Birçok projede tek mimari belgedir.

Ayrıntılı belgeleme için mimari tanımlama dilleri geliştirildi. Daha az yanlış anlamaya yol açarlar, ama pahalıdırlar ve maliyetlerine değip değmeyeceği bilinemez; bu yüzden yaygın değildir.

Bu diyagramlar eleştirilir: İlişkinin türünü ve bileşenlerin dışa açık özelliklerini göstermezler. Kuram ile sanayi pratiği arasındaki bu çelişki, iki farklı kullanımdan kaynaklanır. Tartışma için kutu ve çizgi yeterli ve çok kullanışlıdır; birçok projede tek mimari belge budur. Ayrıntılı belgeleme gerekiyorsa daha kesin gösterimler, yani mimari tanımlama dilleri kullanılabilir. Ama bu pahalı ve uzun bir iştir; maliyetine değip değmeyeceğini bilmek neredeyse imkânsızdır.

Özet: Mimari Tasarıma Giriş

• Mimari tasarım, sistemin ana bileşenlerini ve ilişkilerini belirler; çıktısı bir mimari modeldir.
• Mimari, gereksinim mühendisliğiyle iç içe yürür; çevik süreçlerde de erkenden kurulur.
• İşlevsel olmayan özellikleri asıl belirleyen mimaridir.
• Blok diyagramlar tartışma için yeterlidir; ayrıntılı belgeleme daha kesin gösterim ister.

Teknik olmayan bir yöneticiye, yeni proje için neden bir yazılım mimarına ihtiyaç olduğunu anlatan bir sunumun ana maddelerini yazın.

Özetleyelim. Mimari tasarım, sistemin ana bileşenlerini ve aralarındaki ilişkileri belirler. Mimari, gereksinimlerle iç içe yürür ve çevik süreçlerde de erkenden kurulur. Performans, güvenlik ve bakım kolaylığı gibi özellikleri asıl belirleyen mimaridir. Düşünmeniz için bir soru: Teknik olmayan bir yöneticiye, yeni bir proje için neden yazılım mimarı gerektiğini nasıl anlatırdınız?

Mimari Tasarım Kararları

Bu bölümde mimari tasarım sırasında verilmesi gereken kararlara bakıyoruz. Mimari tasarım yaratıcı bir süreçtir. Hazır bir formülü yoktur; geliştirilen sistemin türüne, mimarın deneyimine ve sistemin özel gereksinimlerine bağlıdır.

Etkinlikler dizisi değil, kararlar dizisi

Bir adımlar listesi gibi düşünmek

Önce şunu yap, sonra şunu… Mimari tasarımda böyle sabit bir sıra yoktur.

Bir kararlar dizisi gibi düşünmek

Mimar, sistemi ve geliştirme sürecini derinden etkileyen yapısal kararlar verir.

Bu yüzden mimari tasarımı bir etkinlikler dizisi olarak değil, verilmesi gereken bir kararlar dizisi olarak düşünmek daha doğrudur. Mimar, bilgisine ve deneyimine dayanarak sistemi ve geliştirme sürecini derinden etkileyen yapısal kararlar verir.

Sekiz temel soru

Kitap, mimarın cevaplaması gereken sekiz temel soru sıralar. Örnek alınabilecek genel bir uygulama mimarisi var mı? Sistem donanıma nasıl dağıtılacak? Hangi mimari desenler kullanılabilir? Sistemi yapılandırmanın temel yaklaşımı ne olacak?

Bileşenler alt bileşenlere nasıl ayrılacak? Bileşenlerin çalışması nasıl kontrol edilecek? İşlevsel olmayan gereksinimler için en iyi organizasyon hangisi? Ve mimari nasıl belgelenecek?

Bunlardan dördüncü, beşinci ve altıncı sorular, Garlan ve Shaw’ın mimari stil kavramının kapsamına girer. Önce istemci-sunucu ya da katmanlı gibi en uygun yapı seçilir. Sonra bileşenlerin alt bileşenlere ayrılma stratejisine karar verilir. Son olarak kontrol modeli kurulur: bileşenlerin çalışmasını kimin, nasıl yöneteceği.

Üç kararı yakından tanıyalım

Genel uygulama mimarisi

Aynı alandaki sistemler, alanın temel kavramlarını yansıtan benzer mimarilere sahiptir. Ürün hatları, bir çekirdek mimari etrafında müşteriye özel çeşitlerle kurulur.

Dağıtım

Gömülü sistemler ve kişisel uygulamalarda gerekmeyebilir. Büyük sistemlerin çoğu ise birçok bilgisayara dağılır; bu karar performansı ve güvenilirliği belirler.

Desen ya da stil

İkisi artık aynı anlamda kullanılır. Desen, farklı sistemlerde kullanılmış bir organizasyonun özüdür; mimar, ortak desenleri, nerede işe yaradıklarını, güçlü ve zayıf yanlarını bilmelidir.

Bu kararlardan üçüne biraz daha yakından bakalım. Genel uygulama mimarisi: Aynı alandaki sistemler, alanın temel kavramlarını yansıtan benzer mimarilere sahiptir. Mimar, sistemin bu genel mimarilerle ortak yanını ve oradan ne kadar bilgiyi yeniden kullanabileceğini belirler. Dağıtım: Gömülü sistemler ve kişisel uygulamalarda dağıtık bir mimari gerekmeyebilir. Ama büyük sistemlerin çoğu birçok bilgisayara dağılır ve dağıtım mimarisi, performansı ve güvenilirliği belirleyen önemli bir karardır. Desen ya da stil: Bu iki terim artık aynı anlamda kullanılıyor. Bir mimari desen, farklı sistemlerde kullanılmış bir organizasyonun özüdür. Mimar, yaygın desenleri, nerede kullanıldıklarını ve güçlü, zayıf yanlarını bilmelidir.

İşlevsel olmayan gereksinim mimariyi seçer

Mimari ile işlevsel olmayan özellikler arasındaki ilişki o kadar sıkıdır ki, stil ve yapı seçimi doğrudan bu gereksinimlere bağlı olmalıdır. Beş özelliğe tek tek bakalım. Performans kritikse, kritik işlemleri az sayıda bileşende toplarız ve bu bileşenleri ağa dağıtmak yerine aynı bilgisayara yerleştiririz. Küçük ve çok sayıda bileşen yerine birkaç büyük bileşen kullanmak, bileşenler arası iletişimi azaltır.

Güvenlik: kritik varlık en içte

Güvenlik kritikse katmanlı bir yapı kullanırız. En kritik varlıkları en içteki katmanlarda korur, bu katmanlara yüksek düzeyde güvenlik doğrulaması uygularız. AS-HYS’de en kritik varlık hasta kayıtlarıdır. Bu kayıtlara ulaşmak isteyen her istek, dıştan içe her katmanın denetiminden geçmek zorundadır.

Emniyet: riskli işlemler tek yerde

Emniyet, yani sistemin insanlara zarar vermemesi kritikse, emniyetle ilgili işlemleri tek bir bileşende ya da az sayıda bileşende bir araya getiririz. Bu, emniyet doğrulamasının maliyetini ve zorluğunu azaltır. Ayrıca bir arıza durumunda sistemi güvenle kapatabilecek bir koruma sistemi eklemeyi mümkün kılar. Bir insülin pompasında doz hesaplama ve sınırlama işlemleri böyle tek bir bileşende toplanır.

Erişilebilirlik: yedekli bileşenler

Erişilebilirlik kritikse, mimariye yedekli bileşenler koyarız. Aynı servisin birden çok kopyası çalışır.

Böylece bir bileşen arızalandığında ya da güncellenirken diğerleri hizmeti sürdürür. Bileşenler sistemi durdurmadan değiştirilip güncellenebilir. Yüksek erişilebilirlik için hata toleranslı mimariler, güvenilir sistemler konusunda ayrıntılı ele alınır.

Bakım kolaylığı: küçük ve bağımsız bileşenler

Bakım kolaylığı kritikse, mimariyi ince taneli, kendi içinde bütün ve kolayca değiştirilebilen bileşenlerle kurarız. Veriyi üretenleri veriyi tüketenlerden ayırır, paylaşılan veri yapılarından kaçınırız. Böylece bir bileşeni değiştirmek diğerlerini etkilemez.

Ölçeklenebilirlik: yük arttıkça büyüyebilmek

Ne demek?

Sistemin, kullanıcı ya da veri miktarı arttığında performansını koruyarak büyüyebilmesi. Sommerville’in beş özelliğinin yanında bugün en sık anılan kalite özelliklerinden biridir.

Mimariye etkisi

Bileşenler kopyalanabilir olmalı: kullanıcı durumunu kendi içinde tutmayan (durumsuz) servisler kolayca çoğaltılır. Darboğaz olabilecek ortak kaynaklar (ör. tek veritabanı) erkenden belirlenmelidir.

AS-HYS’yi tek bir hastaneden bütün ildeki kliniklere açmak, bir ölçeklenebilirlik kararıdır.

Sommerville’in listesi performans, güvenlik, emniyet, erişilebilirlik ve bakım kolaylığından oluşur. Bulut ve web ölçeğindeki sistemlerle birlikte ölçeklenebilirlik ayrıca vurgulanır hâle geldi. Ölçeklenebilirliğin performansla aynı şey olmadığını vurgulayın: Performans bugünkü yükte ne kadar hızlı olduğumuzu, ölçeklenebilirlik yük arttığında bu hızı koruyup koruyamayacağımızı anlatır. Dikey ve yatay ölçeklemeyi istemci-sunucu deseninde ayrıntılı göreceğiz.

Özellikler çatışabilir

Bu ilkeler birbiriyle çatışabilir. Büyük bileşenler performansı iyileştirir; küçük, ince taneli bileşenler ise bakım kolaylığını. İkisi de önemliyse bir uzlaşma bulmak gerekir.

Bunun bir yolu, sistemin farklı parçaları için farklı desenler ya da stiller kullanmaktır. Hız gerektiren çekirdek büyük ve yerel bileşenlerle, sık değişen raporlama kısmı ise küçük bileşenlerle kurulabilir. Güvenlik ise artık neredeyse her zaman kritik bir gereksinimdir. Mimari, güvenliği korurken diğer işlevsel olmayan gereksinimleri de karşılamalıdır.

AS-HYS için mimari kararlar

Gereksinim	AS-HYS’deki karşılığı	Mimari karar
Güvenlik	Hasta kayıtları gizlidir	Katmanlı yapı; hasta verisi en içte, her katmanda yetki denetimi
Erişilebilirlik	Klinik mesai boyunca randevu araması	Randevu servisinin yedekli kopyaları
Performans	Arama sonucu birkaç saniyede gelmeli	Arama ve önbellek aynı sunucuda
Bakım kolaylığı	Raporlama kuralları sık değişir	Rapor üreteci ayrı, küçük bir bileşen
Emniyet	Yanlış ilaç dozu uyarısı	Doz denetimi tek bir bileşende toplanır

Bu ilkeleri örnek sistemimiz AS-HYS üzerinde uygulayalım. Hasta kayıtları gizli olduğu için katmanlı bir yapı kurar, hasta verisini en içe koyarız. Klinik mesai boyunca randevu araması çalışmalı; randevu servisini yedekli çalıştırırız. Arama sonuçları hızlı gelmeli; arama ile önbelleği aynı sunucuda tutarız. Raporlama kuralları sık değişiyor; rapor üretecini ayrı, küçük bir bileşen yaparız. Yanlış ilaç dozu uyarısı gibi emniyetle ilgili denetimleri ise tek bir bileşende toplarız. Görüldüğü gibi tek bir sistemde birden çok ilke, sistemin farklı parçalarında birlikte uygulanır.

Mimariyi değerlendirmek

Asıl sınav kullanımda

Bir mimarinin gerçek testi, sistemin kullanıldığında işlevsel ve işlevsel olmayan gereksinimleri ne kadar karşıladığıdır.

Erken değerlendirme

Tasarım, referans mimarilerle ya da genel mimari desenlerle karşılaştırılabilir. Desenlerin işlevsel olmayan özelliklere etkisi bilinir (Bosch, 2000).

Bir mimariyi değerlendirmek zordur, çünkü asıl sınav sistem kullanıldığında olur: Sistem gereksinimlerini ne kadar karşılıyor? Yine de erken bir değerlendirme yapılabilir: Tasarımı referans mimarilerle ya da genel mimari desenlerle karşılaştırırız. Desenlerin işlevsel olmayan özelliklere etkisi bilindiği için bu karşılaştırma bize çok şey söyler.

Kararları kayda geçirmek

Sekizinci soru, mimarinin nasıl belgeleneceğiydi. Kitabın yayımından sonra bunun için yaygınlaşan pratik bir yöntem var: mimari karar kayıtları. Her önemli karar için kısa bir belge yazılır: bağlam, karar, değerlendirilen seçenekler ve kararın sonuçları. Belge kod deposunda, kodla birlikte tutulur. Böylece aylar sonra biri “bunu neden böyle yaptık?” diye sorduğunda cevap kaybolmaz.

Özet: Mimari Tasarım Kararları

• Mimari tasarım bir kararlar dizisidir; sekiz temel soruya cevap arar.
• Stil ve yapı seçimi işlevsel olmayan gereksinimlere göre yapılır.
• Performans, güvenlik, emniyet, erişilebilirlik ve bakım kolaylığı farklı mimari ilkeler ister; bu ilkeler çatışabilir.
• Çatışma, sistemin farklı parçalarında farklı desenler kullanılarak uzlaştırılır.

Performans ve güvenlik, bir sistemin mimarisinde birbiriyle çatışan gereksinimler olabilir. Bu iddiayı destekleyen bir gerekçe yazın.

Özetleyelim. Mimari tasarım bir kararlar dizisidir. Stil ve yapı seçimi, işlevsel olmayan gereksinimlere göre yapılır; bu gereksinimler farklı ilkeler ister ve çatışabilir. Düşünmeniz için bir soru: Performans ve güvenlik, mimaride neden birbiriyle çatışabilir?

Mimari Görünümler

Bu bölümde mimari görünümlere bakıyoruz. İki soruyu cevaplayacağız: Bir sistemin mimarisini tasarlarken ve belgelerken hangi görünümler işe yarar? Bu modelleri hangi gösterimle çizmeliyiz?

Tek bir diyagram her şeyi gösteremez

Modüller

Sistem hangi modüllere ayrılıyor?

Çalışma zamanı

Süreçler çalışırken birbiriyle nasıl etkileşiyor?

Dağıtım

Bileşenler ağdaki makinelere nasıl yerleşiyor?

Hepsi farklı zamanlarda gereklidir; bu yüzden mimari çoğu zaman birden fazla görünümle anlatılır.

Bir mimari hakkındaki bütün bilgiyi tek bir diyagramda göstermek imkânsızdır, çünkü bir grafik model sistemin yalnızca bir bakış açısını gösterebilir. Sistemin modüllere nasıl ayrıldığını, çalışma zamanında süreçlerin nasıl etkileştiğini ya da bileşenlerin ağa nasıl dağıldığını ayrı ayrı gösterebiliriz. Hepsi farklı zamanlarda işe yaradığı için mimari genellikle birden fazla görünümle anlatılır.

Kruchten’in 4+1 görünüm modeli

Hangi görünümlerin gerektiği konusunda farklı görüşler var. En bilineni Kruchten’in 4+1 görünüm modelidir. Dört temel görünüm vardır: mantıksal, süreç, geliştirme ve fiziksel görünüm.

Bu dört görünüm ortak kullanım durumları ya da senaryolarla birbirine bağlanır. Artı bir, işte bu senaryolardır.

Mantıksal görünüm: temel soyutlamalar

Mantıksal görünüm, sistemin temel soyutlamalarını nesneler ya da nesne sınıfları olarak gösterir. AS-HYS için bunlar hasta, randevu, klinik ve görüşmedir. Her gereksinimi bu görünümdeki bir varlıkla ilişkilendirebilmeliyiz.

Süreç görünümü: çalışma zamanı

Süreç görünümü, sistemin çalışma zamanında birbiriyle etkileşen süreçlerden nasıl oluştuğunu gösterir. AS-HYS’de web sunucusu istekleri karşılar, randevu servisinin iki kopyası çalışır, bildirimler ise ayrı bir işçi süreç tarafından arka planda gönderilir. Bu görünüm, performans ve erişilebilirlik gibi işlevsel olmayan özellikler hakkında karar vermek için kullanışlıdır.

Geliştirme görünümü: kim neyi geliştirir?

Geliştirme görünümü, yazılımın geliştirme için nasıl ayrıştırıldığını gösterir: Her bileşeni tek bir geliştirici ya da ekip gerçekleştirir. Bu görünüm yöneticiler ve programcılar için kullanışlıdır: İşin nasıl bölüneceğini ve kimin hangi modülden sorumlu olduğunu gösterir.

Fiziksel görünüm: hangi yazılım hangi makinede?

Fiziksel görünüm, sistemin donanımını ve yazılım bileşenlerinin işlemciler arasında nasıl dağıtıldığını gösterir. AS-HYS’de klinik bilgisayarları tarayıcıyla web sunucusuna bağlanır; iki uygulama sunucusu ve bir veritabanı sunucusu vardır. Bu görünüm, sistemin kurulumunu planlayan sistem mühendisleri için kullanışlıdır.

+1: bir senaryo bütün görünümleri birleştirir

Artı birdeki senaryolar, dört görünümü birbirine bağlar. Bir senaryoyu bütün görünümlerde izleyelim: Görevli bir hastanın yarınki randevularını arıyor. Mantıksal görünümde hasta, randevu ve klinik sınıfları kullanılır. Süreç görünümünde istek web sunucusundan randevu servisine, oradan veritabanına gider. Geliştirme görünümünde bu iş randevu modülüne, yani randevu ekibine düşer. Fiziksel görünümde ise iki uygulama sunucusundan birinde çalışır. Senaryolar böylece görünümlerin birbiriyle tutarlı olup olmadığını sınamamızı sağlar.

Kavramsal görünüm

Hofmeister ve arkadaşları

Benzer görünümlere bir de kavramsal görünüm ekler: sistemin soyut bir görünümü. Üst düzey gereksinimleri ayrıntılı belirtimlere ayrıştırmanın temelidir; yeniden kullanılabilecek bileşenler hakkında karar vermeye yardım eder; tek bir sistem yerine bir ürün hattını temsil edebilir.

Pratikte

Kavramsal görünüm tasarım sırasında neredeyse her zaman çizilir. Bölümün başındaki paketleme robotu diyagramı bir kavramsal görünümdür. Diğer görünümler ilgili konu tartışılırken çizilir; hepsini eksiksiz çizmek nadiren gerekir.

Hofmeister ve arkadaşları benzer görünümler önerir, ama bunlara bir de kavramsal görünüm ekler: sistemin soyut bir görünümü. Bu görünüm üst düzey gereksinimleri ayrıntılı belirtimlere ayırmanın temelidir, yeniden kullanılabilecek bileşenler hakkında karar vermeye yardım eder ve bir ürün hattını temsil edebilir. Bölümün başındaki paketleme robotu diyagramı bir kavramsal görünümdü. Pratikte kavramsal görünüm neredeyse her zaman çizilir. Diğer görünümler ise ilgili konu tartışılırken çizilir; bütün görünümleri eksiksiz hazırlamak nadiren gerekir.

Hangi gösterim? UML tartışması

UML yanlısı görüş

2006’da yapılan bir anket, mimaride UML’in çoğunlukla gayriresmî kullanıldığını gösterdi. Anketi yapanlara göre bu kötü bir şeydi: Gösterim kurallarına uyulmalıydı.

Sommerville’in görüşü

UML nesneye dayalı sistemler için tasarlandı; mimari aşamada daha yüksek soyutlama gerekir, sınıflar uygulamaya fazla yakındır. Tasarım sırasında tahtaya hızla çizilen gayriresmî gösterimler daha kullanışlıdır. UML, ayrıntılı belgelemede ve model güdümlü geliştirmede değerlidir.

Mimariyi hangi gösterimle çizeceğimiz de tartışmalıdır. 2006’da yapılan bir anket, UML’in mimaride çoğunlukla gayriresmî kullanıldığını gösterdi; anketi yapanlar bunun kötü olduğunu savundu. Sommerville bu görüşe katılmaz. UML nesneye dayalı sistemler için tasarlanmıştır; mimari aşamada ise daha yüksek bir soyutlama gerekir ve sınıflar uygulamaya fazla yakındır. Tasarım sırasında tahtaya hızla çizilebilen gayriresmî gösterimler daha kullanışlıdır. UML’in asıl değeri, mimariyi ayrıntılı belgelerken ve model güdümlü geliştirmede ortaya çıkar.

Mimari tanımlama dilleri (ADL)

Bazı araştırmacılar mimariyi tanımlamak için daha uzmanlaşmış diller önerir: mimari tanımlama dilleri. Bu dillerin temel öğeleri bileşenler ve bağlayıcılardır; iyi biçimlenmiş bir mimari için kurallar da içerirler. Ama uzmanlık dilleri oldukları için alan uzmanları onları anlamakta zorlanır. Model güdümlü geliştirmede bir yerleri olabilir, ama ana akım olmaları beklenmez.

Ne kadar belge?

Çevik bakış

Ayrıntılı tasarım belgelerinin çoğu hiç kullanılmaz; onları üretmek zaman ve para kaybıdır.

Sommerville’in önerisi

Kritik sistemler dışında dört görünümün hepsini ayrıntılı çizmeye değmez. İletişime yarayan görünümleri geliştirin; belgenin eksiksiz olup olmadığına takılmayın.

Çevik yöntemleri kullananlar, ayrıntılı tasarım belgelerinin çoğunun hiç kullanılmadığını, bu yüzden onları üretmenin zaman ve para kaybı olduğunu söyler. Sommerville de büyük ölçüde katılır: Kritik sistemler dışında dört görünümün hepsini ayrıntılı çizmeye değmez. İletişime yarayan görünümleri geliştirin, belgenin eksiksiz olup olmadığına takılmayın.

Bugün yaygın bir yaklaşım: C4 modeli

Kitabın yayımından sonra yaygınlaşan bir yaklaşımdan da söz edelim: C4 modeli. C4, aynı sistemi bir haritaya yakınlaşır gibi dört ayrıntı düzeyinde gösterir: bağlam, konteyner, bileşen ve kod. Kutu ve çizgi diyagramlarına dayanır, ama her kutunun türü ve her çizginin anlamı yazılır. Böylece blok diyagramlara yöneltilen eleştiriye pratik bir cevap verir.

Özet: Mimari Görünümler

• Mimari tek bir çizimle anlatılamaz; birden fazla görünüm gerekir.
• 4+1: mantıksal, süreç, geliştirme, fiziksel görünümler ve onları bağlayan senaryolar.
• Kavramsal görünüm neredeyse her zaman çizilir; diğerleri gerektiğinde.
• Tasarımda gayriresmî gösterimler, ayrıntılı belgelemede UML; ADL’ler yaygın değil.

Bir tren istasyonundaki bilet makinesi için kavramsal görünümü ve süreç görünümünü gösteren diyagramlar çizin.

Özetleyelim. Mimari tek bir çizimle anlatılamaz. 4+1 modeli dört görünüm önerir ve onları senaryolarla birbirine bağlar. Kavramsal görünüm neredeyse her zaman çizilir. Kendiniz deneyin: Bir tren istasyonundaki bilet makinesi için kavramsal görünümü ve süreç görünümünü çizin.

Mimari Desenler: MVC ve Katmanlı Mimari

Bu bölümde mimari desenlere bakıyoruz ve en çok kullanılan iki desenle başlıyoruz: Model-View-Controller ve katmanlı mimari.

Desen nedir?

Bir mimari desen, farklı sistemlerde ve ortamlarda denenmiş ve sınanmış iyi tasarım pratiğinin stilize, soyut bir tanımıdır.

Desen yalnızca bir çizim değildir: ne zaman uygun olduğunu, ne zaman olmadığını, güçlü ve zayıf yanlarını da anlatır.

Bir mimari desen, farklı sistemlerde ve ortamlarda denenmiş, başarısı kanıtlanmış iyi tasarım pratiğinin soyut bir tanımıdır. Desen yalnızca bir çizim değildir. Ne zaman kullanılması uygun olduğunu, ne zaman olmadığını, güçlü ve zayıf yanlarını da anlatmalıdır.

Desenlerin kısa geçmişi

Desen fikrinin yazılımdaki yolculuğuna kısaca bakalım. Doksanlı yılların başında Garlan ve Shaw, sistem organizasyonlarını mimari stiller olarak tanımladı. Asıl tetikleyici 1995’te yayımlanan nesneye dayalı tasarım desenleri kitabı oldu. Ardından 1996 ile 2007 arasında desen yönelimli yazılım mimarisi üzerine beş ciltlik bir el kitabı serisi çıktı. Bugün örgüt tasarımından kullanılabilirliğe, yapılandırma yönetimine kadar birçok alanda desenler kullanılıyor.

Bir desen nasıl anlatılır?

Alan	İçerik
Ad	Desenin adı
Açıklama	Sistemin nasıl organize edildiği
Örnek	Desenin kullanıldığı bir sistem ve diyagramı
Ne zaman kullanılır?	Desenin uygun olduğu durumlar
Avantajlar	Desenin güçlü yanları
Dezavantajlar	Desenin zayıf yanları, bedeli

Desenler standart bir biçimde, anlatım ve diyagramların karışımıyla tanımlanır: adı, kısa bir açıklaması, bir örnek sistem, ne zaman kullanılacağı, avantajları ve dezavantajları. Bu bölümdeki her deseni bu şablonla inceleyeceğiz.

Bu bölümdeki desenler

Bu bölümde beş genel mimari desen ve kontrol desenlerini göreceğiz. Her desen başka bir soruya cevap verir.

MVC arayüz ile veriyi ayırır, katmanlı mimari bütün sistemi düzenler. İkisi de sistemin kavramsal organizasyonunu gösterir. Depo, bağımsız araçların veriyi nasıl paylaşacağını anlatır; bu sistemin durağan yapısıdır. İstemci-sunucu ve boru ve filtre ise çalışma zamanındaki organizasyonu gösterir: hizmetin sunulması ve verinin dönüştürülmesi. Kontrol desenleri de bileşenleri kimin çalıştıracağını anlatır. Her desenden sonra bu haritaya dönüp bir öncekinin neyi çözdüğünü ve neyi açıkta bıraktığını konuşacağız.

MVC: hangi sorunu çözer?

Model-View-Controller deseninin çözdüğü sorunla başlayalım. Karmaşık kullanıcı arayüzlü uygulamalarda veri erişimi, iş kuralları ve arayüz kodu çoğu zaman aynı dosyanın içinde iç içe geçer. Buna spagetti kod denir. Böyle bir kodda arayüzü değiştirmek iş kuralını, veritabanını değiştirmek arayüzü bozar.

MVC: üç rol

MVC, sunum ve etkileşimi sistemin verisinden ayırır. Sistem birbiriyle etkileşen üç mantıksal bileşene bölünür. Model, sistemin verisini ve bu veri üzerindeki işlemleri yönetir. View, verinin kullanıcıya nasıl gösterileceğini tanımlar. Controller ise tuş basma ve fare tıklaması gibi kullanıcı etkileşimlerini yönetir ve bunları View ile Model’e iletir.

Bileşenler arasındaki ilişkiler şöyledir: Kullanıcı olayları Controller’a gelir. Controller hangi görünümün gösterileceğini seçer ve Model’in durumunu değiştirir. Model değiştiğinde View’a haber verir; View de güncel durumu Model’den sorgulayarak ekranı yeniden çizer.

Örnek akış: randevu iptali

Bu ilişkileri AS-HYS’de bir randevunun iptal edilmesi üzerinde adım adım izleyelim.

Görevli ekranda İptal düğmesine basar. Bu olay Controller’a gelir.

Controller, kullanıcının eylemini Model’de bir güncellemeye çevirir: Randevu nesnesinin iptal işlemini çağırır. İş kuralı, örneğin geçmiş bir randevunun iptal edilemeyeceği, burada, Model’in içinde denetlenir.

Model durumunu değiştirir ve View’a bir değişiklik bildirimi gönderir.

View, Model’den güncel durumu sorgular ve randevu listesini yeniden çizer. Görevli, randevunun iptal edildiğini ekranda görür. Her bileşen yalnızca kendi işini bilir. Bu sayede ekranı değiştirmek iş kuralına, iş kuralını değiştirmek ekrana dokunmayı gerektirmez.

MVC’nin web uygulamasındaki hâli

Bu, desenin kavramsal görünümüydü. Kitap, aynı desenin bir web uygulamasında çalışma zamanındaki hâlini de gösterir. Tarayıcıdan gelen HTTP isteğini Controller karşılar: isteği işler, uygulamaya özgü mantığı çalıştırır ve veriyi doğrular. Model iş mantığını ve veritabanını yönetir. View ise dinamik sayfayı ve formları üretip tarayıcıya gönderir. Aynı desenin iki farklı görünümle anlatılması, önceki bölümde gördüğümüz görünüm fikrinin bir örneğidir.

MVC deseni

Alan	MVC (Model-View-Controller)
Açıklama	Sunum ve etkileşimi sistem verisinden ayırır; sistem Model, View ve Controller bileşenlerine bölünür.
Örnek	MVC ile organize edilmiş web uygulaması mimarisi.
Ne zaman kullanılır?	Veriyi görüntülemenin ve onunla etkileşmenin birden çok yolu varsa; sunum ve etkileşimle ilgili gelecekteki gereksinimler bilinmiyorsa.
Avantajlar	Veri, gösteriminden bağımsız değişebilir (ve tersi). Aynı veri farklı biçimlerde gösterilir; birindeki değişiklik hepsine yansır.
Dezavantajlar	Veri modeli ve etkileşim basitse ek kod ve karmaşıklık getirebilir.

MVC desenini şablonumuzla özetleyelim. Ne zaman kullanılır? Veriyi görüntülemenin ve onunla etkileşmenin birden çok yolu varsa ya da sunumla ilgili gelecekteki gereksinimler henüz bilinmiyorsa. Avantajı, verinin gösteriminden bağımsız değişebilmesi ve aynı verinin farklı biçimlerde gösterilebilmesidir. Dezavantajı, basit uygulamalarda gereksiz kod ve karmaşıklık getirmesidir.

MVC pratikte

Paralel geliştirme

Ön yüz geliştiricileri View üzerinde, arka uç geliştiricileri Model ve Controller üzerinde aynı anda çalışabilir.

Test edilebilirlik

İş mantığı arayüzden bağımsız olduğu için Model için birim testi yazmak kolaydır.

Yaygınlık

Django, Ruby on Rails, ASP.NET MVC, Laravel gibi web çatılarının temelidir. Masaüstü ve mobilde MVP ve MVVM çeşitleri kullanılır.

Pratikte MVC iki önemli kazanç daha sağlar. Paralel geliştirme: Ön yüz ve arka uç ekipleri aynı anda çalışabilir. Test edilebilirlik: İş mantığı arayüzden bağımsız olduğu için kolayca test edilir. MVC, Django, Rails ve Laravel gibi web çatılarının temelidir. Masaüstü ve mobil uygulamalarda ise Model-View-Presenter ve Model-View-ViewModel gibi çeşitleri kullanılır.

MVC’den katmanlı mimariye

MVC’den katmanlı mimariye geçelim.

MVC arayüzü veriden ayırdı; Model, View ve Controller birbirinden bağımsız değişebiliyor. Ama bu ayrım yalnızca kullanıcı etkileşimi etrafında. Arayüzün ardındaki büyük sistem açıkta kalıyor: İş kuralları, güvenlik, veritabanı ve işletim sistemi desteği nasıl düzenlenecek?

Katmanlı mimari aynı ayrım fikrini bütün sisteme uygular: Sorumluluklar üst üste katmanlara bölünür. Hedef yine ayrım ve bağımsızlıktır.

Katmanlı mimari: ayrım ve bağımsızlık

Ayrım ve bağımsızlık, mimari tasarımın temel kavramlarıdır, çünkü değişikliklerin yerel kalmasını sağlarlar. MVC bunu bir yoldan yapıyordu; katmanlı mimari başka bir yoldur. Sistemin işlevleri ayrı katmanlara bölünür. Bu genel modelde en altta işletim sistemi ve veritabanı gibi sistem desteği, üstünde uygulama işlevleri, onun üstünde arayüz yönetimi ile kimlik doğrulama, en üstte de kullanıcı arayüzü vardır.

Her katman yalnızca hemen altındaki katmanın sunduğu servislere dayanır ve üstündeki katmana servis sağlar. En alttaki katmanlar, sistemin her yerinde kullanılan temel servislerdir. Katman sayısı keyfidir; her katman gerekirse iki ya da daha fazla katmana bölünebilir.

Sorumlulukların ayrılması: üç katmanlı yapı

Katmanlı mimarinin temel ilkesi sorumlulukların ayrılmasıdır: Her katmanın tek ve net bir görevi vardır. En yaygın hâli, sistemi üç katmana ayıran klasik üç katmanlı yapıdır. Sunum katmanı kullanıcı arayüzünü yönetir: Kullanıcıdan girdiyi alır ve sonucu gösterir. İş kurallarının nasıl çalıştığını bilmez.

İş mantığı katmanı uygulamanın beynidir: İş kurallarını, süreçleri ve hesaplamaları içerir. Verinin nereden geldiğini ya da nasıl gösterileceğini bilmez.

Veri erişim katmanı verinin kalıcı olarak saklanmasından ve okunmasından sorumludur; iş kurallarından habersizdir.

Bu ayrımın pratik bir kazancı daha var: Katmanlar farklı teknolojilerle geliştirilebilir. Sunum katmanı React ile, iş mantığı Java ile, veri katmanı PostgreSQL üzerinde kurulabilir. Katmanlar birbirleriyle yalnızca arayüzleri üzerinden konuştuğu sürece, farklı ekipler birbirini etkilemeden çalışabilir.

Katman kuralı ve ihlali

Katmanlı mimarinin bütün faydası tek bir kurala dayanır: Bir üst katman yalnızca hemen altındaki katmanla konuşur.

Pratikte katmanlar arasında temiz bir ayrım sağlamak çoğu zaman zordur. Geliştiriciler zaman kazanmak için kuralı delip üst katmandan alt katmana doğrudan erişebilir. Bu kestirmeler çoğaldıkça katmanlar birbirine sızar ve katmanlı mimarinin faydası kaybolur.

Bir katmanı değiştirmek

Katmanlı mimarinin en güçlü yanı değiştirilebilirliktir. Veri erişim katmanının üstündeki arayüze dikkat edin.

Veritabanını değiştirmek istediğimizde yalnızca veri erişim katmanını değiştiririz. Arayüz korunduğu sürece iş mantığı ve sunum katmanları bu değişiklikten etkilenmez. Benzer şekilde, makineye bağımlı kısımlar alt katmanlarda toplandığı için sistemi başka bir işletim sistemine ya da veritabanına taşımak için yalnızca bu katmanları yeniden yazmak yeterlidir. Katmanlı yapı artımlı geliştirmeyi de destekler: Bir katman geliştirildikçe sunduğu servislerin bir kısmı kullanıcılara açılabilir.

Örnek: iLearn dijital öğrenme sistemi

Kitap, okullarda bütün derslerin öğrenimini destekleyen dijital öğrenme sistemi iLearn’ün dört katmanlı mimarisini örnek verir. En üstte tarayıcı tabanlı arayüz vardır. Altında grup, uygulama ve kimlik yönetimi gibi yapılandırma servisleri; onun altında e-posta, video konferans ve sanal sınıf gibi uygulama servisleri; en altta kimlik doğrulama, kayıt ve depolama gibi yardımcı servisler yer alır. Bir diğer katmanlı örnek de uygulama mimarileri kısmında göreceğimiz AS-HYS mimarisidir.

Katmanlı mimari deseni

Alan	Katmanlı mimari
Açıklama	Sistem, ilgili işlevlerin bir arada olduğu katmanlara ayrılır; her katman üstündekine servis sağlar. Temel ilke: sorumlulukların ayrılması.
Örnek	Okullar için iLearn dijital öğrenme sistemi.
Ne zaman kullanılır?	Mevcut sistemlerin üzerine yeni olanaklar kurulurken; geliştirme her katmandan bir ekibin sorumlu olduğu birkaç ekibe dağılmışsa; çok düzeyli güvenlik gerekiyorsa.
Avantajlar	Arayüz korunduğu sürece katmanlar bütünüyle değiştirilebilir (ör. veritabanını değiştirmek yalnızca veri katmanını etkiler). Katmanlar farklı teknolojilerle, farklı ekiplerce geliştirilebilir. Güvenilirlik için olanaklar (ör. kimlik doğrulama) birden çok katmanda tekrarlanabilir.
Dezavantajlar	Temiz ayrım pratikte zordur; kural delinip alt katmanlara doğrudan erişilirse soyutlama sızar (leaky abstraction). İstek her katmanda yorumlandığı için performans düşebilir. Hiçbir iş yapmadan isteği aşağı aktaran gereksiz katmanlar bu maliyeti boşuna artırır.

Katmanlı mimariyi de şablonla özetleyelim.

Ne zaman kullanılır? Mevcut sistemlerin üzerine yeni olanaklar kurarken, geliştirme her biri bir katmandan sorumlu ekiplere dağılmışsa ve çok düzeyli güvenlik gerekiyorsa.

Avantajı katmanların değiştirilebilmesi ve farklı teknolojilerle geliştirilebilmesidir. Dezavantajları ise temiz ayrımın pratikte zor olması, kural delindiğinde soyutlamanın sızması ve isteğin her katmanda yeniden yorumlanması yüzünden performansın düşebilmesidir.

Özet: Mimari Desenler: MVC ve Katmanlı Mimari

• Desen, denenmiş iyi pratiğin tanımıdır; ne zaman kullanılacağını ve bedelini de söyler.
• MVC veriyi (Model), sunumu (View) ve etkileşimi (Controller) ayırır.
• Katmanlı mimari sistemi, her biri yalnızca altındakine dayanan katmanlara böler.
• İkisinin ortak hedefi: ayrım ve bağımsızlık; değişiklikler yerel kalır.

Aynı randevu verisini hem web sayfasında hem mobil uygulamada göstermek istiyoruz. MVC’nin hangi özelliği bunu kolaylaştırır?

Özetleyelim. MVC veriyi, sunumu ve etkileşimi ayırır. Katmanlı mimari sistemi, her biri yalnızca altındakine dayanan katmanlara böler. İkisinin de hedefi ayrım ve bağımsızlıktır. Düşünmeniz için: Aynı randevu verisini hem web sayfasında hem mobil uygulamada göstermek istiyoruz. MVC’nin hangi özelliği bunu kolaylaştırır?

Mimari Desenler: Depo, İstemci-Sunucu, Boru ve Filtre

Mimari desenlere devam ediyoruz. Bu bölümde üç desen var: depo, istemci-sunucu ve boru ve filtre. Sonunda kontrol desenlerine ve desenlerin karşılaştırmasına bakacağız. MVC ve katmanlı mimari, sistemin kavramsal organizasyonunu gösteriyordu. Bu desenler ise başka sorulara cevap veriyor: Bileşenler veriyi nasıl paylaşır, hizmet nasıl dağıtılır, veri adım adım nasıl işlenir?

Kavramsal organizasyondan veri paylaşımına

İkinci desen grubuna geçerken haritaya dönelim.

MVC ve katmanlı mimari sistemin kavramsal organizasyonunu gösterdi: Parçaların nasıl gruplandığını ve kimin kime servis verdiğini. Ama başka bir soru açıkta: Birçok bağımsız araç aynı büyük veri üzerinde çalışacaksa, birbirine sıkı sıkıya bağlanmadan bu veriyi nasıl paylaşır?

Depo deseni bu soruya cevap verir: Bileşenler birbirleriyle değil, ortak bir veri deposu üzerinden konuşur.

Depo mimarisi: ortak veri, bağımsız araçlar

Bazı sistemlerin merkezinde karmaşık bir veri yapısı vardır ve farklı araçların bu veri üzerinde birbirinden bağımsız çalışması gerekir. Depo deseninde sistemdeki bütün veri, bütün bileşenlerin erişebildiği merkezi bir depoda tutulur.

Kitaptaki örnek, model güdümlü geliştirmeyi destekleyen bir tümleşik geliştirme ortamıdır: UML editörleri, kod üreteçleri, Java ve Python editörleri, tasarım çevirici, tasarım analizcisi ve rapor üreteci. Kural şudur: Bileşenler birbirleriyle doğrudan konuşmaz, yalnızca depo aracılığıyla etkileşir. Her araç ürettiği bilgiyi depoya bırakır, diğer araçlar onu oradan alır.

Örneğin bir geliştirici UML editöründe modeli günceller. Yeni model depoya yazılır.

Depoya veri girmesi bir eylemi tetikleyebilir: Kod üreteci yeni modeli depodan okur ve kodu üretir. UML editörü kod üretecinin varlığından haberdar bile değildir. Bu depo sürüm denetimli bir ortam da olabilir: Yazılımdaki değişiklikleri izler ve önceki sürümlere dönmeyi sağlar.

Depo deseninin bedeli: ortak veri modeli

Depo, büyük miktarda veriyi paylaşmanın verimli bir yoludur; veriyi bir bileşenden diğerine açıkça aktarmaya gerek kalmaz. Ama bütün bileşenler üzerinde anlaşılmış ortak bir veri modeli etrafında çalışmak zorundadır. Bu model, her aracın özel ihtiyaçları arasında kaçınılmaz bir uzlaşmadır. Veri modeli uymayan yeni bir aracı eklemek zor, hatta imkânsız olabilir. Depoyu birden çok makineye dağıtmak da zordur: Mantıksal olarak merkezi bir depo dağıtılabilir, ama bu verinin birden çok kopyasını tutmak ve bu kopyaları tutarlı tutmak demektir.

Pasif depo ve kara tahta

IDE örneğindeki depo pasiftir: Kontrol, depoyu kullanan araçlardadır. Ne zaman okuyup yazacaklarına kendileri karar verir.

Yapay zekâ sistemleri için geliştirilmiş bir alternatif ise kara tahta modelidir. Burada belirli bir veri oluştuğunda tahta ilgili bileşeni tetikler. Bu model, depodaki veri yapılandırılmamışsa uygundur: Hangi aracın çalışacağına ancak veri analiz edildikten sonra karar verilebilir.

Depo deseni

Alan	Depo (Repository)
Açıklama	Bütün veri, bütün bileşenlerin erişebildiği merkezi bir depoda yönetilir. Bileşenler doğrudan değil, yalnızca depo üzerinden etkileşir.
Örnek	Araçların tasarım bilgisini bir depoda paylaştığı IDE.
Ne zaman kullanılır?	Uzun süre saklanması gereken büyük hacimde bilgi üretiliyorsa; depoya veri girmesinin bir eylemi tetiklediği veri güdümlü sistemlerde. Komuta-kontrol, yönetim bilgi sistemleri, CAD ve IDE’ler.
Avantajlar	Bileşenler bağımsızdır, birbirinin varlığını bilmez; yeni bir araç mevcutları değiştirmeden eklenir. Bir bileşenin değişikliği hepsine yayılır. Bütün veri tek yerde olduğu için güvenlik, yedekleme ve tutarlılık merkezi yönetilir.
Dezavantajlar	Depo tek hata noktasıdır. Çok sayıda bileşen aynı anda okuyup yazarsa depo bir performans darboğazına dönüşür. Depoyu birden çok bilgisayara dağıtmak, kopyaları tutarlı tutmayı gerektirdiği için zordur.

Depo desenini şablonla özetleyelim.

Uzun süre saklanması gereken büyük hacimde bilgi üreten sistemlerde ve depoya veri girmesinin bir eylemi tetiklediği veri güdümlü sistemlerde kullanılır.

Avantajı bileşenlerin bağımsızlığı ve verinin merkezi, tutarlı yönetimidir. Dezavantajı ise deponun tek hata noktası olması, yoğun kullanımda darboğaza dönüşmesi ve dağıtım zorluğudur.

Depodan istemci-sunucuya

Depodan istemci-sunucuya geçiyoruz.

Depo, büyük veriyi tek merkezde verimli ve tutarlı biçimde paylaştı. Ama bize sistemin durağan yapısını anlattı; çalışma zamanında neyin nerede çalıştığını ve sistemin nasıl dağıtılacağını göstermedi. Üstelik depo tek hata noktasıydı ve birden çok makineye dağıtılması zordu. Açıkta kalan soru şu: Farklı yerlerdeki çok sayıda kullanıcıya bir hizmeti ağ üzerinden nasıl sunarız ve yük arttığında ne yaparız?

İstemci-sunucu deseni bir çalışma zamanı organizasyonudur: Hizmetler ayrı sunucularda çalışır, istemciler bu hizmetlere istek göndererek erişir. Sunucular çoğaltılarak yük de karşılanabilir.

İstemci-sunucu: hizmetler ve kullanıcıları

Depo deseni sistemin durağan yapısıyla ilgilenir, çalışma zamanını göstermez. İstemci-sunucu deseni ise dağıtık sistemlerde yaygın bir çalışma zamanı organizasyonunu anlatır. Üç ana bileşeni vardır: hizmet sunan sunucular, bu hizmetleri kullanan istemciler ve istemcilerin hizmetlere eriştiği bir ağ. İstemciler sunucuların adlarını ve sundukları hizmetleri bilmek zorundadır. Sunucuların ise istemcilerin kim olduğunu ya da kaç istemcinin bağlandığını bilmesi gerekmez.

İstemci, istek-cevap protokolüyle, örneğin HTTP ile bir istek gönderir ve cevap gelene kadar bekler.

Sunucu isteği işler ve sonucu cevap olarak geri gönderir. Bugün kullandığımız internetin büyük kısmı bu basit döngü üzerine kuruludur. İstemci-sunucu mimarisi genellikle dağıtık sistem olarak düşünülür, ama bağımsız hizmetlerden oluşan bu mantıksal model tek bir bilgisayarda da kurulabilir. Yine asıl fayda ayrım ve bağımsızlıktır.

Örnek: film ve fotoğraf kütüphanesi

Kitaptaki örnek, çok kullanıcılı, web tabanlı bir film ve fotoğraf kütüphanesidir. İstemci programı, tarayıcıyla kurulmuş tümleşik bir arayüzdür.

Farklı medya türlerini farklı sunucular yönetir. Neden ayrı sunucular? Video kareleri hızlı ve eşzamanlı aktarılmalıdır, ama görece düşük çözünürlükte; video sunucusu sıkıştırma ve açmayı farklı biçimlerde yapabilir. Fotoğraflar ise yüksek çözünürlükte saklanmalıdır; bu yüzden ayrı bir sunucuda tutulur. Katalog sunucusu çeşitli sorguları karşılar ve filmle ilgili bilgilere ve satış sistemine bağlantılar sağlar.

Bu modelin en önemli avantajı dağıtık olmasıdır: Yeni bir sunucu eklemek ya da bir sunucuyu yükseltmek, sistemin diğer kısımlarını etkilemeden yapılabilir.

Modern bir örnek: Netflix

Kitaptaki film kütüphanesi, istemci-sunucu deseninin küçük ölçekli bir örneğiydi. Aynı fikrin bugün yüz milyonlarca kullanıcıya hizmet veren hâline bakalım: Netflix. Burada anlatacağımız yapı, Netflix’in kendi mühendislik blogu ve ByteByteGo gibi kaynaklardaki kamuya açık anlatımlara dayanan sadeleştirilmiş bir görünümdür. İstemciler televizyon, telefon ve tarayıcıdaki uygulamalardır.

İlk büyük parça buluttaki kontrol düzlemidir. Kullanıcı Oynat düğmesine basana kadar olan her şey burada olur: oturum açma, katalogda gezinme, arama ve öneriler. İstemcilerin istekleri önce bir API ağ geçidine gelir. Ağ geçidi isteği doğrular ve ilgili servise yönlendirir. Arkada her biri kendi işinden sorumlu yüzlerce küçük servis, yani mikroservis çalışır: kimlik, katalog, öneri, oynatma. Veriler dağıtık veritabanlarında ve önbelleklerde, olaylar ise bir olay akışı platformunda tutulur.

İkinci büyük parça veri düzlemidir: Netflix’in kendi içerik dağıtım ağı, Open Connect. Videoların kendisi buluttan değil, internet servis sağlayıcılarının içine ve internet değişim noktalarına yerleştirilmiş binlerce önbellek sunucusundan gelir. Yani video sunucusu, izleyicinin fiziksel olarak hemen yanına taşınmıştır.

Kullanıcı Oynat’a bastığında ne olur? İstemci, oynatma servisine bir istek gönderir. Oynatma servisi, kullanıcının yetkisini ve cihazını denetler; ardından o kullanıcı için en uygun, genellikle en yakın önbellek sunucularının adreslerini istemciye döndürür.

Bundan sonra video akışı doğrudan bu yakındaki önbellek sunucusundan gelir; bulut, akışın içinde yer almaz. Dikkat edin: Kontrol ile veri birbirinden ayrılmıştır. Hafif istekler bulutta işlenir, ağır video trafiği ise izleyicinin yanında. Bu, kitaptaki film kütüphanesinde katalog ile videonun ayrı sunucularda tutulması fikrinin dev ölçekli hâlidir.

Bir videonun yolculuğu: boru ve filtre

Videoların o önbellek sunucularına nasıl geldiğine bakalım. Burada bölümün bir sonraki deseni, boru ve filtre karşımıza çıkıyor. Stüdyodan gelen yüksek kaliteli kaynak video önce küçük parçalara bölünür.

Her parça birbirinden bağımsız olarak, aynı anda birçok makinede kodlanır. Her parça için farklı çözünürlük ve bit hızlarında onlarca sürüm üretilir: 4K televizyon için de, zayıf bağlantılı bir telefon için de.

Kodlanmış parçalar birleştirilir, korumalı içerik için şifrelenir ve paketlenir. Son adımda videolar, izleyiciler istemeden önce, trafiğin düşük olduğu saatlerde önbellek sunucularına dağıtılır. Böylece izleyici Oynat’a bastığında video zaten yanındadır.

Neden bu kadar çok sürüm? Oynatma sırasında istemci bağlantı hızını sürekli ölçer ve sürümler arasında geçiş yapar. Buna uyarlanabilir bit hızı denir: Bağlantı yavaşlarsa görüntü kalitesi düşer, ama video durmaz. Kodlama hattı tipik bir boru ve filtre sistemidir: Her adım tek bir dönüşüm yapar ve parçalar paralel işlenir.

Film kütüphanesinden Netflix’e

	Kitaptaki film kütüphanesi	Netflix (sadeleştirilmiş)
İstemci	Tarayıcıdaki tümleşik arayüz	TV, telefon ve tarayıcı uygulamaları
Katalog ve iş mantığı	Tek katalog sunucusu	API ağ geçidi ve yüzlerce mikroservis
Video sunucusu	Tek video sunucusu	İnternet servis sağlayıcılarının içindeki binlerce önbellek sunucusu (Open Connect)
Sıkıştırma	Sunucuda, istek anında	Önceden, her video için onlarca sürüm (boru ve filtre hattı)
Ölçekleme	Sunucu eklemek	Bulut bölgeleri ve otomatik ölçekleme; içerik izleyicinin yakınına taşınır
Tek hata noktası	Her sunucu	Yedekli servisler; arızalar bilerek tetiklenip sınanır (kaos mühendisliği)

Desen aynı: hizmetler ayrı sunucularda, istemciler istekle erişir. Değişen, ölçek ve bu ölçeğin getirdiği işlevsel olmayan gereksinimler.

Tabloyu satır satır okuyun ve her satırda hangi işlevsel olmayan gereksinimin değişime yol açtığını sorun: Ölçeklenebilirlik mikroservisleri, performans içerik dağıtım ağını, erişilebilirlik yedekliliği ve kaos mühendisliğini getirdi. Bölümün başındaki “işlevsel olmayan gereksinim mimariyi seçer” fikrine bağlayın. Netflix, arızalara dayanıklılığı sınamak için üretim ortamında rastgele sunucuları kapatan araçlar geliştirmesiyle de bilinir (Chaos Monkey). Kaynaklar: Netflix TechBlog (netflixtechblog.com), ByteByteGo “Netflix tech stack” yazıları. Ayrıntılar zamanla değişir; burada önemli olan mimari fikirdir.

Yük artınca: darboğaz ve ölçekleme

İstemci-sunucu mimarisinde bütün istemciler aynı sunucuya istek gönderir.

İstemci sayısı arttıkça sunucu bir darboğaza dönüşür: İstekler sırada bekler, cevaplar gecikir. Sunucu çökerse de hiçbir istemci hizmet alamaz; sunucu tek hata noktasıdır.

Dikey ve yatay ölçekleme

Bu sorunun iki çözümü var. Dikey ölçeklemede aynı sunucuyu güçlendiririz: daha çok işlemci, daha çok bellek. Basittir, ama bir sınırı vardır ve sunucu yine tek hata noktası olarak kalır.

Yatay ölçeklemede ise sunucu sayısını artırırız. Önlerine bir yük dengeleyici konur; gelen istekleri sunucular arasında dağıtır. Böylece hem kapasite artar hem de bir sunucu düştüğünde diğerleri hizmeti sürdürür. Sommerville’in istemci-sunucu deseni için söylediği “sunucular çoğaltılabilir” ifadesinin bugünkü karşılığı budur.

İstemci-sunucu deseni

Alan	İstemci-sunucu (Client-server)
Açıklama	Sistem bir hizmetler kümesidir; her hizmeti ayrı bir sunucu sağlar. İstemciler bu hizmetlerin kullanıcılarıdır.
Örnek	İstemci-sunucu olarak organize edilmiş film ve video kütüphanesi.
Ne zaman kullanılır?	Ortak bir veritabanına farklı yerlerden erişilmesi gerekiyorsa. Sunucular çoğaltılabildiği için yükü değişken sistemlerde de.
Avantajlar	Merkezi yönetim: veri ve iş mantığı sunucuda; güncelleme ve güvenlik tek yerden yapılır. Erişim: ağa bağlı her yetkili istemci hizmeti kullanabilir. Ölçekleme: sunucu güçlendirilebilir (dikey) ya da çoğaltılabilir (yatay). Genel bir işlev (ör. yazdırma) bütün istemcilere açıktır.
Dezavantajlar	Her hizmet tek hata noktasıdır; hizmet engelleme (DoS) saldırılarına açıktır. Çok sayıda istekte sunucu darboğaza dönüşür. Performans ve güvenilirlik ağ bağlantısına bağlıdır. Sunucular farklı kuruluşlara aitse yönetim sorunları çıkar.

İstemci-sunucu desenini özetleyelim.

Ortak bir veritabanına farklı yerlerden erişilmesi gerektiğinde ve sunucular çoğaltılabildiği için yükü değişken sistemlerde kullanılır. Merkezi yönetim, erişim kolaylığı ve ölçeklenebilirlik avantajlarıdır.

Dezavantajı, her hizmetin tek hata noktası olması, yoğun yükte darboğaz oluşması ve ağa bağımlılıktır. Bugün bu sorunlar yük dengeleyiciler ve çoğaltılmış sunucularla hafifletilir.

İstemci-sunucudan boru ve filtreye

İstemci-sunucudan boru ve filtreye geçelim.

İstemci-sunucu hizmeti ağa dağıttı. Etkileşimi bir istek ve cevap olarak düşündük: İstemci istek gönderir ve cevabı bekler. Peki iş bir isteğe cevap vermek değil de verinin adım adım dönüştürülmesiyse? Haftalık faturaları işlemek ya da bir programı derlemek gibi. Burada bekleyen bir istemci yoktur; veri bir aşamadan diğerine akar.

Boru ve filtre deseni bu işi, her biri tek bir dönüşüm yapan adımlardan oluşan bir veri akışı olarak düzenler. Bu da bir çalışma zamanı organizasyonudur.

Boru ve filtre: bir montaj hattı

Son genel desenimiz boru ve filtre. Bu, işlevsel dönüşümlerin girdileri işleyip çıktı ürettiği bir çalışma zamanı organizasyonudur. Veri bir dönüşümden diğerine akar ve yol boyunca dönüştürülür. Her işlem adımı bir filtredir; filtreler arasında veriyi taşıyan bağlantılar borudur. Bir filtre verinin nereden geldiğini ya da nereye gideceğini bilmez; yalnızca kendi işini yapar. Dönüşümler sırayla ya da paralel çalışabilir; veri öğe öğe ya da tek bir toplu iş olarak işlenebilir.

Adın kaynağı: UNIX boruları

Desenin adı UNIX’ten gelir. UNIX’te süreçler, bir metin akışını birinden diğerine aktaran borularla birbirine bağlanabilir. Bu komut zincirinde her komut bir filtredir, dikey çizgi ise bir borudur: Dosyalar listelenir, Kasım ayına ait satırlar süzülür, bunlardan metin dosyaları ayıklanır ve satırlar sayılır. Filtre adı da buradan gelir: Her dönüşüm, girdi akışından işleyebildiği veriyi süzer.

Örnek: fatura ve ödeme işleme

Kitaptaki örnek, toplu işleme yapan bir fatura sistemidir. Kuruluş müşterilerine fatura keser; haftada bir, yapılan ödemeler faturalarla eşleştirilir. İlk filtre kesilmiş faturaları okur. İkinci filtre bunları ödeme kayıtlarıyla karşılaştırıp ödemeleri belirler.

Ödenmiş faturalar için makbuz düzenlenir.

Süresi içinde ödenmemiş faturalar için ise ayrı bir hatta vadesi geçmiş ödemeler bulunur ve hatırlatma gönderilir. Bu iş akışı biçimi birçok iş sürecinin yapısına doğrudan uyar. Sisteme yeni bir adım eklemek, araya yeni bir filtre koymak kadar kolaydır.

Nerede uygun, nerede değil?

Toplu sıralı (batch)

Dönüşümler sırayla, veri toplu işlenir. Faturalama gibi veri işleme sistemlerinin yaygın mimarisidir.

Süreç hattı

Gömülü sistemlerde her süreç eşzamanlı çalışan bir filtre olur; sensörden gelen veri hat boyunca işlenir.

Etkileşimli arayüzler

Grafik arayüzlerin girdi-çıktısı karmaşıktır ve kontrol, fare tıklaması gibi olaylara dayanır; bunu sıralı bir veri akışına çevirmek zordur.

Bu desenin çeşitleri bilgisayarların ilk veri işleme günlerinden beri kullanılıyor. Dönüşümler sırayla çalışıp veri toplu işlendiğinde desen, toplu sıralı modele dönüşür: faturalama gibi veri işleme sistemlerinin yaygın mimarisi. Gömülü sistemler de her sürecin eşzamanlı çalıştığı bir süreç hattı olarak kurulabilir. Etkileşimli sistemler ise bu desene uymaz. Grafik arayüzlerin girdi ve çıktısı karmaşıktır ve kontrol, fare tıklaması ya da menü seçimi gibi olaylara dayanır. Bunu sıralı bir veri akışına çevirmek zordur.

Boru ve filtre deseni

Alan	Boru ve filtre (Pipe and filter)
Açıklama	Her işlem bileşeni (filtre) ayrıdır ve tek bir veri dönüşümü yapar. Veri, bir borudaki gibi bir bileşenden diğerine akar.
Örnek	Faturaları işleyen boru ve filtre sistemi.
Ne zaman kullanılır?	Girdilerin ayrı aşamalarda işlenip ilgili çıktıların üretildiği veri işleme uygulamalarında (toplu ya da işlem tabanlı).
Avantajlar	Anlaşılması kolaydır; dönüşümlerin yeniden kullanımını destekler. İş akışı biçimi birçok iş sürecine uyar. Dönüşüm ekleyerek geliştirmek kolaydır. Sıralı ya da eşzamanlı kurulabilir.
Dezavantajlar	Veri aktarım biçimi üzerinde anlaşılmalıdır. Her dönüşüm girdisini ayrıştırıp çıktısını bu biçime çevirmek zorundadır; bu ek yük getirir ve uyumsuz veri yapılı bileşenleri yeniden kullanmayı imkânsız kılabilir.

Boru ve filtre desenini özetleyelim. Girdilerin ayrı aşamalarda işlendiği veri işleme uygulamalarında kullanılır. Anlaşılması kolaydır, dönüşümlerin yeniden kullanımını destekler ve yeni dönüşümler eklenerek kolayca geliştirilir. Dezavantajı, veri biçimi üzerinde anlaşma zorunluluğudur. Her filtre girdisini ayrıştırıp çıktısını ortak biçime çevirmek zorundadır; bu ek yük getirir ve farklı veri yapıları kullanan bileşenleri yeniden kullanmayı imkânsız kılabilir.

Yapıdan kontrole

Desenleri bitirmeden önce bir soruya daha bakalım.

Gördüğümüz desenler yapıyı ve veri akışını anlattı: Hangi bileşenler var ve veri nereden nereye gidiyor. Ama mimari tasarım kararlarındaki altıncı soru hâlâ açık: Bileşenleri kim, ne zaman çalıştırır? Bir denetleyici mi çağırır, yoksa bileşenler olaylara mı tepki verir?

Kontrol desenleri bu kararı verir: merkezi kontrol ya da olay tabanlı kontrol.

Kontrol desenleri

Kitap ayrıca sistemdeki kontrolün nasıl örgütleneceğine dair desenlerden söz eder. Bu, sekiz temel sorudan altıncısının cevabıdır. Merkezi kontrolde bir bileşen diğerlerini çağırır ve onların çalışmasını yönetir.

Olay tabanlı kontrolde ise sistem dış olaylara tepki verir. Bir olay yayımlanır; o olayla ilgilenen bileşenler kendiliğinden devreye girer. Olayı yayımlayan, kimin dinlediğini bilmez. Bugün mesaj kuyrukları ve olay akışı platformları üzerine kurulan olay güdümlü mimariler, bu fikrin büyük ölçekli hâlidir.

Desenler bir arada

Desen	Gösterdiği görünüm	Güçlü yanı	Zayıf yanı
MVC	Kavramsal	Veri ile sunum ayrı değişir	Basit sistemde fazla kod
Katmanlı	Kavramsal	Katmanlar değiştirilebilir	Temiz ayrım zor, performans
Depo	Statik yapı	Büyük veriyi verimli paylaşır	Tek hata noktası, ortak şema
İstemci-sunucu	Çalışma zamanı	Dağıtılabilir, ölçeklenir	Ağa bağımlı, tek hata noktası
Boru ve filtre	Çalışma zamanı	Basit, yeniden kullanılabilir	Ortak veri biçimi, etkileşime uymaz

Gerçek sistemler desenleri birleştirir: bir web uygulaması istemci-sunucu, sunucu tarafı katmanlı, arayüzü MVC olabilir.

Desenleri yan yana koyalım. Dikkat edin, desenler sistemin farklı görünümlerini gösterir: MVC ve katmanlı mimari kavramsal organizasyonu, depo durağan yapıyı, istemci-sunucu ve boru ve filtre ise çalışma zamanını. Bu yüzden gerçek sistemler desenleri birleştirir. Bir web uygulaması dağıtım açısından istemci-sunucu, sunucu tarafında katmanlı, arayüzünde MVC olabilir. Uygulama mimarilerinde bunun örneklerini göreceğiz.

Özet: Mimari Desenler: Depo, İstemci-Sunucu, Boru ve Filtre

• Depo: bileşenler yalnızca ortak depo üzerinden veri paylaşır.
• İstemci-sunucu: hizmetler ayrı sunuculardadır; istemciler istek gönderir.
• Boru ve filtre: veri, tek iş yapan filtrelerden geçerek dönüştürülür.
• Kontrol: merkezi ya da olay tabanlı olabilir. Gerçek sistemler desenleri birleştirir.

Çiftlikte sığırları otonom olarak güden, gerektiğinde insan operatörlerce uzaktan kumanda edilebilen dronlar için birden çok desen nasıl birlikte kullanılabilir?

Özetleyelim. Depo deseni veriyi ortak bir depoda paylaşır. İstemci-sunucu hizmetleri sunuculara dağıtır. Boru ve filtre veriyi tek iş yapan adımlarla dönüştürür. Gerçek sistemler bu desenleri birleştirir. Düşünmeniz için bir soru: Sığırları otonom olarak güden ve gerektiğinde uzaktan kumanda edilebilen dronlar için birden çok desen nasıl birlikte kullanılabilir?

Uygulama Mimarileri

Bu bölümde uygulama mimarilerine bakıyoruz. Uygulama sistemleri bir işletmenin ya da kurumun ihtiyacını karşılamak için vardır. Bütün işletmelerin pek çok ortak ihtiyacı vardır: personel alır, fatura keser, hesap tutar.

Ortak ihtiyaçlar, ortak mimariler

Genel iş işlevleri

Personel, faturalama, muhasebe… Her işletmede benzerdir.

Sektöre özgü işlevler

Bütün telefon şirketleri aramaları bağlar ve ölçer, şebekeyi yönetir, fatura keser.

Uygulama mimarisi

Bir sistem sınıfının temel özelliklerini yakalayan, yeniden kullanılabilir yapı. Ayrıntıda farklı sistemler aynı iskeleti paylaşır.

Aynı sektördeki işletmeler sektöre özgü uygulamalar da kullanır. Örneğin bütün telefon şirketlerinin aramaları bağlayan ve ölçen, şebekeyi yöneten ve fatura kesen sistemlere ihtiyacı vardır. Bu ortaklıklar, belirli sistem türlerinin yapısını anlatan uygulama mimarilerinin doğmasına yol açtı. Uygulama mimarisi, bir sistem sınıfının temel özelliklerini yakalar. Sistemler ayrıntıda farklı olsa da ortak yapı yeni sistemlerde yeniden kullanılabilir.

E-ticaret ve uçak rezervasyonu: aynı iskelet

Bir e-ticaret sitesi ile bir uçak rezervasyon sistemi ilk bakışta çok farklı görünür. Birinde ürün satılır, diğerinde koltuk. Ama adımları yan yana koyduğumuzda benzerlik ortaya çıkar.

İkisi de kullanıcının isteğini alır, bir kaynağı, yani stoku ya da koltuğu denetler, veritabanını günceller ve bir onay verir. İkisi de aynı hareket işleme iskeletini paylaşır. Uygulama mimarisi işte bu ortak iskelettir: Belirli bir problem türü için kendini kanıtlamış, yeniden kullanılabilir bir şablon. Sıfırdan başlamak yerine bu şablondan yola çıkarız.

Yeniden kullanım çoğu zaman örtüktür

Uygulama mimarisi yeni bir sistem geliştirilirken baştan uygulanabilir. Ama birçok iş sisteminde yeniden kullanım örtüktür: Genel bir uygulama sistemi yapılandırılarak yeni bir uygulama oluşturulur. Kurumsal kaynak planlama sistemleri ve muhasebe ya da stok yönetimi gibi hazır, yapılandırılabilir sistemler böyledir. Standart bir mimarileri ve bileşenleri vardır; bileşenler yapılandırılıp uyarlanarak belirli bir işletmeye uygun hâle getirilir.

Uygulama mimarilerinin beş kullanımı

1 · Başlangıç noktası

Uygulama türünü bilmiyorsanız ilk tasarımı genel mimariye dayandırıp özelleştirirsiniz; boş sayfadan başlamazsınız.

2 · Tasarım kontrol listesi

Tasarımınızı genel mimariyle karşılaştırırsınız: Kimlik doğrulama, kayıt tutma, ödeme gibi standart bileşenleri düşündük mü?

3 · Ekip organizasyonu

Kararlı bileşenler paralel geliştirilebilir; iş bileşenlere göre dağıtılır: arayüz ekibi, API ekibi, veritabanı ekibi.

4 · Yeniden kullanım değerlendirmesi

Elinizdeki bileşenleri (ör. bir ödeme modülü) genel yapıdaki karşılıklarıyla karşılaştırırsınız.

5 · Ortak sözcük dağarcığı

“Bu bir hareket işleme sistemi” demek, sistemin doğası, zorlukları ve gereksinimleri hakkında hemen ortak bir anlayış yaratır.

Bir tasarımcı olarak uygulama mimarilerini beş şekilde kullanabilirsiniz. Başlangıç noktası olarak: Geliştirdiğiniz uygulama türüne yabancıysanız, ilk tasarımı genel mimariye dayandırıp sonra özelleştirirsiniz. Tasarım kontrol listesi olarak: Kendi tasarımınızı genel mimariyle karşılaştırırsınız; kimlik doğrulama, kayıt tutma ya da ödeme gibi standart konuları atlayıp atlamadığınızı görürsünüz. Ekip organizasyonu için: Mimarinin kararlı bileşenleri çoğu zaman paralel geliştirilebilir.

Yeniden kullanımı değerlendirmek için: Elinizdeki bileşenleri genel yapıdaki karşılıklarıyla karşılaştırırsınız. Ve ortak bir sözcük dağarcığı olarak: Bir sistemin hareket işleme sistemi olduğunu söylemek, onun hakkında hemen ortak bir anlayış yaratır.

Farklı görünen uygulamalar, ortak iskelet

Hareket işleme uygulamaları

Veritabanı merkezli; kullanıcı isteklerini işler, veritabanını günceller. En yaygın etkileşimli iş sistemleri: bankacılık, e-ticaret, bilgi sistemleri, rezervasyon.

Dil işleme sistemleri

Kullanıcının niyeti biçimsel bir dille ifade edilir. Sistem bu dili iç biçime çevirir ve yorumlar: derleyiciler, sorgu dilleri, XML gibi işaretleme dilleri.

Uygulama türleri ilk bakışta çok farklı görünebilir, ama ortak bir soyut mimari paylaşabilir. Kitap bunu iki tür üzerinden gösterir. Hareket işleme uygulamaları veritabanı merkezlidir: Kullanıcıların bilgi isteklerini işler ve veritabanını günceller. Etkileşimli iş sistemlerinin en yaygın türüdür. Dil işleme sistemlerinde ise kullanıcının niyeti bir programlama dili gibi biçimsel bir dille ifade edilir. Web tabanlı iş sistemlerinin çoğu hareket işleme sistemidir; bütün yazılım geliştirme ise dil işleme sistemlerine dayanır.

Veritabanı işlemi: ya hepsi ya hiçbiri

Hareket işleme sistemlerinin merkezinde veritabanı işlemi kavramı vardır. Teknik olarak bir veritabanı işlemi, tek bir birim olarak, yani atomik olarak ele alınan bir işlemler dizisidir. ATM’den para çekmeyi düşünelim: Bakiye kontrol edilir, bakiyeden tutar düşülür ve ATM’ye parayı vermesi için komut gönderilir.

Peki üçüncü adımda bağlantı koparsa ne olur? Bakiye düşülmüş, ama para verilmemiştir.

İşlem atomik olduğu için bütün adımlar tamamlanmadan veritabanındaki değişiklikler kalıcı hâle gelmez. Bir adım başarısız olursa işlem bütünüyle geri alınır. Böylece işlemin içindeki bir hata veritabanını tutarsız bırakmaz. Hareket işleme sistemleri, kullanıcıların eylemlerinin birbirine karışmaması ve veritabanı bütünlüğünün korunması için bu şekilde örgütlenir.

Kullanıcının gözünden işlem

Kullanıcı işlemi

Bir amacı karşılayan tutarlı bir işlemler dizisi. Örneğin: “Dr. Yılmaz’ın yarınki boş randevu saatlerini bul.”

Veritabanı işlemi gerekir mi?

Bu istek veritabanını değiştirmez; teknik bir veritabanı işlemi olarak paketlenmesi gerekmeyebilir. Randevuyu kaydetmek ise veritabanını değiştirir ve atomik olmalıdır.

Kullanıcı açısından işlem, bir amacı karşılayan tutarlı bir işlemler dizisidir. AS-HYS’de bir görevlinin bir doktorun yarınki boş saatlerini araması böyle bir kullanıcı işlemidir. Bu istek veritabanını değiştirmediği için teknik bir veritabanı işlemi olarak paketlenmesi gerekmeyebilir. Ama randevuyu kaydetmek veritabanını değiştirir ve atomik olmalıdır.

Hareket işleme uygulamalarının yapısı

Hareket işleme sistemleri genellikle kullanıcıların zamanlaması belirsiz, yani eşzamansız hizmet istekleri gönderdiği etkileşimli sistemlerdir. Kavramsal yapıları dört bileşenden oluşur. Önce kullanıcı, bir girdi-çıktı işleme bileşeni aracılığıyla sisteme bir istek gönderir.

İstek, uygulamaya özgü mantıkla işlenir. Bir işlem oluşturulur ve genellikle veritabanı yönetim sisteminin içinde yer alan işlem yöneticisine verilir.

İşlem yöneticisi işlemin düzgün tamamlandığından emin olduktan sonra uygulamaya işlemin bittiğini bildirir.

ATM sisteminin mimarisi: girdi, işlem, çıktı

Hareket işleme sistemleri, girdi, işlem ve çıktıdan sorumlu bileşenlerle bir boru ve filtre mimarisi olarak da örgütlenebilir. Banka örneğinde sistem iki yazılımdan oluşur: ATM’deki yazılım ve bankanın veritabanı sunucusundaki hesap işleme yazılımı. Girdi ve çıktı ATM’de, işlem ise bankanın sunucusunda gerçekleşir.

Girdi aşamasında ATM müşterinin hesap numarasını alır, kartı doğrular ve müşterinin istediği hizmeti seçmesini sağlar.

İşlem aşamasında bankanın sunucusu hesabı sorgular ve günceller.

Çıktı aşamasında yine ATM bilgileri yazdırır, kartı iade eder ve parayı verir. Bir hareket işleme sistemi böylece bir boru ve filtre hattı gibi okunabilir.

Bilgi sistemleri: katmanlı genel model

Ortak bir veritabanıyla etkileşen bütün sistemler, işlem tabanlı bilgi sistemleri olarak düşünülebilir. Bilgi sistemi, kütüphane kataloğu, uçuş tarifesi ya da hastanedeki hasta kayıtları gibi büyük bir bilgi tabanına denetimli erişim sağlar. Bilgi sistemleri neredeyse her zaman web tabanlıdır. Kitap, bilgi sistemleri için katmanlı bir genel model önerir. En üstte kullanıcı arayüzü, en altta veritabanı vardır. Kullanıcı iletişimi katmanı arayüzdeki bütün girdi ve çıktıyı yönetir; bilgi erişimi katmanı veritabanına erişen ve onu güncelleyen uygulamaya özgü mantığı içerir.

AS-HYS: genel modelin bir örneği

Kitaptaki Mentcare sistemi, bizim örnek sistemimiz AS-HYS’dir. Bu genel modelin bir örneğidir; her katmanı bileşenleriyle dolduralım. En üstte tarayıcı tabanlı bir arayüz vardır. İkinci katman, tarayıcı üzerinden sunulan arayüz işlevlerini sağlar: Kullanıcıların oturum açması, yaptıkları işlemin rollerine uygun olup olmadığını denetleyen rol denetimi, bilgileri sunan form ve menü yönetimi ve bilgilerin tutarlılığını kontrol eden veri doğrulama.

Üçüncü katman sistemin işlevlerini gerçekleştirir: güvenlik yönetimi, hasta bilgilerinin oluşturulup güncellenmesi, başka veritabanlarıyla veri alışverişi ve yönetim raporlarını üreten rapor üreteçleri.

En alt katman ticari bir veritabanı yönetim sistemiyle kurulur; işlem yönetimini ve kalıcı veri saklamayı sağlar. Bu mimari, katmanlı mimari deseninin de bir örneğidir. Desenler ve uygulama mimarileri böyle iç içe geçer.

E-ticaret: kaynak yönetimi ve alışveriş sepeti

Bilgi ve kaynak yönetim sistemleri bazen hareket işleme sistemidir de. E-ticaret sistemleri, mal ya da hizmet için elektronik sipariş alıp teslimatı düzenleyen, internet tabanlı kaynak yönetim sistemleridir. Uygulamaya özgü katmanda ek bir işlev bulunur: alışveriş sepeti. Kullanıcı ürünleri ayrı ayrı işlemlerle sepete ekler.

Sonra hepsini tek bir işlemle birlikte öder.

“Sipariş ver”e basınca neler olur?

Web tabanlı bir bilgi sisteminde “Sipariş ver” düğmesine bastığımızda arka planda neler olduğunu, çok katmanlı mimari üzerinde adım adım izleyelim.

Tarayıcı sipariş bilgilerini bir HTTP isteğiyle web sunucusuna gönderir. Web sunucusu kullanıcı iletişiminden sorumludur: Oturumu denetler ve formdaki verinin geçerli olduğunu doğrular.

Ardından isteği uygulama sunucusuna iletir. Burada iş kuralları çalışır: Ürün stokta var mı, fiyat ve indirim ne, ödeme onaylandı mı?

Uygulama sunucusu veritabanı sunucusunda tek bir işlem başlatır: Stoktan düşer ve siparişi yazar. Bu işlem atomiktir; biri başarısız olursa ikisi birden geri alınır.

İşlem tamamlanınca onay geriye doğru akar: Uygulama sunucusu sonucu web sunucusuna verir, web sunucusu onay sayfasını oluşturup tarayıcıya gönderir. Her katman yalnızca kendi işini yapar. Talep arttığında ise her katmana ayrı ayrı sunucu eklenebilir.

Çok katmanlı istemci-sunucu ve ölçekleme

Bu sistemlerdeki sunucuların düzeni genellikle dört katmanlı genel modeli yansıtır ve çok katmanlı bir istemci-sunucu mimarisi olarak kurulur. Web sunucusu bütün kullanıcı iletişiminden, uygulama sunucusu uygulamaya özgü mantıktan ve bilgi erişiminden, veritabanı sunucusu ise veritabanıyla veri alışverişinden ve işlem yönetiminden sorumludur.

Birden çok sunucu kullanmak yüksek iş hacmi sağlar ve dakikada binlerce işlemi karşılamayı mümkün kılar. Talep arttıkça ek yükü karşılamak için her düzeye sunucu eklenebilir.

Diğer uygulama türleri

Veri işleme uygulamaları

Büyük veri kümelerini bir biçimden diğerine dönüştürür; çoğunlukla kullanıcı etkileşimi olmadan arka planda, toplu ya da akış olarak çalışır. Gün sonu raporları, veri ambarı (ETL) işlemleri, video sıkıştırma.

Olay işleme sistemleri

Dış dünyadan gelen olay akışlarına (sensör verisi, tıklamalar) anında tepki verir; eşzamansız ve tepkisel çalışır. Dolandırıcılık tespiti, nesnelerin interneti verisi, alarm sistemleri.

Kitabın web sitesinde toplu veri işleme, kaynak ayırma ve olay tabanlı düzenleme sistemlerinin mimarileri de yer alır.

Kitap iki türe odaklanıyor, ama sık karşılaşacağınız iki tür daha var. Veri işleme uygulamaları büyük veri kümelerini bir biçimden diğerine dönüştürür; genellikle kullanıcı etkileşimi olmadan, toplu ya da akış olarak arka planda çalışır. Olay işleme sistemleri ise sensör verisi ya da tıklamalar gibi olay akışlarına anında tepki verir.

Özet: Uygulama Mimarileri

• Uygulama mimarileri, bir sistem sınıfının ortak iskeletini yakalar; başlangıç noktası, kontrol listesi ve ortak dil olarak kullanılır.
• Hareket işleme sistemleri veritabanını atomik işlemlerle günceller; girdi, işlem ve çıktı olarak da okunabilir.
• Bilgi sistemleri katmanlı bir genel modele uyar; katmanlar sunuculara eşlenip her düzeyde ölçeklenir.

Bilgi sistemlerinin genel modelini kullanarak, kullanıcıların etkinlikleri, boş biletleri ve fiyatları görüp bilet satın alabileceği bir bilet satış sisteminin bileşenlerini önerin.

Özetleyelim. Uygulama mimarileri bir sistem sınıfının ortak iskeletini yakalar. Hareket işleme sistemleri veritabanını atomik işlemlerle günceller; bilgi sistemleri ise katmanlı bir genel modele uyar ve katmanlar sunuculara eşlenerek ölçeklenir. Kendiniz deneyin: Bilgi sistemlerinin genel modelini kullanarak bir etkinlik bileti satış sisteminin bileşenlerini önerin.

Dil İşleme Sistemleri

Uygulama mimarilerine dil işleme sistemleriyle devam ediyoruz. Bu bölümde bir dil işleme sisteminin genel yapısına, derleyicinin bileşenlerine ve aynı derleyicinin iki farklı desenle nasıl kurulabileceğine bakacağız. Sonunda referans mimarilere ve güncel bir mimari tartışmaya değineceğiz.

Dil işleme sistemleri

Bir dili başka bir gösterime çevirir; programlama dilleri için ortaya çıkan kodu çalıştırabilir de.

Derleyiciler

Programlama dilini makine koduna çevirir.

XML ve sorgu dilleri

XML veri tanımını bir veritabanı sorgusuna ya da başka bir XML gösterimine çevirir.

Doğal dil işleme

Bir doğal dili başka birine, örneğin Fransızcayı Norveççeye çevirir; sözlük gibi ek bileşenler içerir.

Dil işleme sistemleri bir dili o dilin başka bir gösterimine çevirir; programlama dilleri için ortaya çıkan kodu çalıştırabilir de. Derleyiciler programlama dilini makine koduna çevirir. Başka dil işleme sistemleri bir XML veri tanımını veritabanı sorgusuna çevirebilir. Doğal dil işleme sistemleri ise bir doğal dili başka birine çevirir.

Her gün kullandığımız dil işleme sistemleri

Dil işleme sistemleri yalnızca derleyiciler değildir; her gün kullandığımız birçok aracın temelinde bu mimari vardır. Derleyici, Java ya da C++ ile yazdığımız kaynak kodu çalıştırılabilir makine koduna çevirir.

Bir SQL sorgu motoru, yazdığımız SELECT sorgusunu çözümler, bir sorgu planına çevirir ve veritabanı üzerinde çalıştırır.

Bash gibi bir komut satırı kabuğu, yazdığımız komutu yorumlar ve ilgili sistem çağrısını tetikler. Bu bir yorumlayıcıdır.

Web tarayıcısı da bir dil işleme sistemidir: HTML ve CSS kodunu okur, çözümler ve ekranda gördüğümüz sayfayı oluşturur. Hepsinde aynı iskelet vardır: Girdi çözümlenir, iç bir gösterime çevrilir, sonra çalıştırılır ya da başka bir biçime dönüştürülür.

Çevirici ve yorumlayıcı

Bir programlama dili için dil işleme sisteminin olası mimarisine bakalım. Kaynak dil komutları çalıştırılacak programı tanımlar. Çevirici sözdizimini ve anlamı denetler, ardından bunları soyut bir makinenin komutlarına çevirir.

Bu komutları başka bir bileşen, yorumlayıcı çalıştırır: Komutları getirir ve gerekirse ortamdan gelen veriyi kullanarak çalıştırır. Çıktı, komutların girdi verisi üzerinde yorumlanmasının sonucudur.

Birçok derleyicide yorumlayıcı, makine komutlarını işleyen sistem donanımıdır; soyut makine gerçek bir işlemcidir. Python ya da Ruby gibi dinamik tipli dillerde ise yorumlayıcı bir yazılım bileşenidir.

Derleyicinin bileşenleri

Bileşen	Görevi
Sözcüksel analizci	Girdi dilindeki sözcükleri (token) alır, iç biçime çevirir.
Sembol tablosu	Çevrilen metindeki varlıkların (değişken, sınıf, nesne adları) bilgisini tutar.
Sözdizimsel analizci	Dilin tanımlı dilbilgisine göre sözdizimini denetler, sözdizim ağacını kurar.
Sözdizim ağacı	Derlenen programı temsil eden iç yapı.
Anlamsal analizci	Ağaç ve sembol tablosundan yararlanarak anlamsal doğruluğu denetler.
Kod üreteci	Sözdizim ağacını “dolaşır” ve soyut makine kodu üretir.

Ek olarak ağacı analiz edip dönüştüren bir en iyileyici (optimizer), üretilen kodu daha verimli hâle getirebilir.

Daha geniş bir programlama ortamının parçası olan derleyicilerin genel bir mimarisi vardır. Sözcüksel analizci girdi dilinin sözcüklerini iç biçime çevirir. Sembol tablosu değişken ve sınıf adları gibi varlıkların bilgisini tutar. Sözdizimsel analizci dilbilgisine göre sözdizimini denetler ve sözdizim ağacını kurar. Anlamsal analizci, ağaç ve sembol tablosundan yararlanarak anlamsal doğruluğu denetler. Kod üreteci ise ağacı dolaşarak soyut makine kodu üretir. Ağacı dönüştürerek üretilen kodu daha verimli kılan bir en iyileyici de eklenebilir.

Boru ve filtre derleyici

Dil işleme sistemlerinde farklı desenler kullanılabilir. Derleyiciler, depo ile boru ve filtre modelinin bir bileşimi olarak gerçekleştirilebilir. Sözcüksel, sözdizimsel ve anlamsal analiz ile kod üretimi sırayla çalışır.

Fazlar, paylaşılan sembol tablosu ve sözdizim ağacı üzerinden iletişir; bunlar ortak bir depo gibidir. Bu model, programların kullanıcı etkileşimi olmadan derlendiği toplu ortamlarda etkilidir; örneğin bir XML belgesini başka birine çevirirken.

Depo tabanlı dil işleme ortamı

Derleyici başka araçlarla tümleşik bir programlama ortamının parçasıysa, sistemi bir depo etrafında örgütlemek daha iyidir. Sembol tablosu ve sözdizim ağacı merkezi bilgi deposudur; normalde araçların içine gömülü olan dilbilgisi tanımı ve çıktı biçimi tanımı da depoya taşınmıştır.

Araçlar ve araç parçaları depo üzerinden iletişir. Böylece sözdizimini denetleyen bir editör, program yazılırken sözdiziminin doğru olup olmadığını anında kontrol edebilir. Bir biçimlendirici de farklı sözdizim öğelerini vurgulayan, okunması kolay listeler üretebilir. Bir bileşendeki değişikliğin diğerlerine hemen yansıması gereken bu tür etkileşimli ortamlarda depo modeli, boru ve filtre modelinden daha uygundur.

Referans mimariler

Nedir?

Bir alandaki sistem mimarilerinin önemli özelliklerini yakalar. Bir uygulama mimarisinde olabilecek her şeyi içerir; gerçekte tek bir uygulamanın hepsini içermesi pek olası değildir.

Ne işe yarar?

Tasarım önerilerini değerlendirmek ve karşılaştırmak; insanlara o alandaki mimari özellikleri öğretmek. Mimari değerlendirmede karşılaştırma noktası olarak kullanılır.

Uygulama mimarileriyle yakından ilişkili bir kavram da referans mimarilerdir. Referans mimari, bir alandaki sistem mimarilerinin önemli özelliklerini yakalar. Bir uygulama mimarisinde olabilecek her şeyi içerir; gerçekte tek bir uygulamanın hepsini içermesi pek olası değildir. Asıl amacı tasarım önerilerini değerlendirmek, karşılaştırmak ve insanlara o alandaki mimari özellikleri öğretmektir.

Bugün: tek parça mı, mikroservis mi?

Son olarak, kitabın yayımından sonra yaygınlaşan bir mimari tartışmaya değinelim: Sistem tek parça mı olmalı, yoksa mikroservislerden mi oluşmalı? Tek parça bir mimaride AS-HYS tek bir uygulama ve tek bir veritabanıdır. Geliştirmesi, test edilmesi ve kurulması görece basittir.

Mikroservis mimarisinde her iş yeteneği kendi verisine sahip, ayrı kurulan küçük bir servistir. Servisler bağımsız geliştirilir, kurulur ve ölçeklenir. Bedeli ise ağ üzerinden iletişim, dağıtık verinin tutarlılığı ve işletim karmaşıklığıdır. Yani bu da bölümün başında gördüğümüz gibi bir işlevsel olmayan gereksinim ödünleşimidir: Bakım kolaylığı ve ölçeklenebilirlik kazanılırken performans ve basitlikten ödün verilir. Mikroservisler, istemci-sunucu ve depo desenlerinin bugünkü bir yorumu olarak da okunabilir.

Özet: Dil İşleme Sistemleri

• Dil işleme sistemleri bir çevirici ve soyut makineyi çalıştıran bir yorumlayıcıdan oluşur.
• Derleyiciler toplu ortamda boru ve filtre, etkileşimli ortamlarda depo etrafında kurulur.
• Referans mimariler tasarımları değerlendirmek ve öğretmek için kullanılır.

Dil işleme sistemlerinin genel modelini kullanarak, doğal dildeki komutları SQL gibi bir dildeki veritabanı sorgularına çeviren bir sistemin mimarisini tasarlayın.

Özetleyelim. Dil işleme sistemleri bir çevirici ve bir yorumlayıcıdan oluşur. Derleyiciler toplu ortamlarda boru ve filtre, etkileşimli ortamlarda depo etrafında kurulur. Referans mimariler ise tasarımları değerlendirmek ve öğretmek için kullanılır. Kendiniz deneyin: Doğal dildeki komutları veritabanı sorgularına çeviren bir sistemin mimarisini, dil işleme sistemlerinin genel modelini kullanarak tasarlayın.

Bölüm Özeti

Bölümü toparlarken her konuyu cevapladığı soruyla birlikte hatırlatın. Amaç, öğrencinin elinde bir mimari karar haritası kalması.

Hangi soru, hangi kavram?

Soru	Kavram	Akılda kalacak
Mimari neden önemli?	İşlevsel olmayan özellikler	Performans, güvenlik, bakım kolaylığını asıl mimari belirler
Hangi kararları veririz?	Sekiz temel soru	Stil ve yapı seçimi işlevsel olmayan gereksinimlere göre yapılır
Mimariyi nasıl anlatırız?	4+1 ve kavramsal görünüm	Tek çizim yetmez; iletişime yarayan görünümleri çizin
Hazır çözüm var mı?	Mimari desenler	MVC, katmanlı, depo, istemci-sunucu, boru ve filtre
Benzer sistemler nasıl kurulur?	Uygulama mimarileri	Hareket işleme, bilgi sistemleri, dil işleme

Tabloyu soldan sağa okuyun: Önce soruyu sorun, sonra öğrencilerden kavramı bulmalarını isteyin. AS-HYS örneğinin her bölümde nasıl ele alındığını hatırlatın: işlevsel olmayan gereksinim tablosu, 4+1 görünümleri, MVC ile randevu iptali, katmanlı bilgi sistemi mimarisi.

Akılda kalacaklar

• Mimari, sistemin iskeletidir; sonradan değiştirmek pahalıdır, bu yüzden çevik süreçlerde de erkenden kurulur.
• Her mimari karar bir ödünleşimdir; tek bir “en iyi” mimari yoktur.
• Desenler, denenmiş çözümleri bedelleriyle birlikte aktarır; gerçek sistemler desenleri birleştirir.
• Mimariyi belgelemenin amacı eksiksizlik değil, iletişimdir; kararların gerekçesi kayda geçmelidir.

Maddeleri okumak yerine sorun: “AS-HYS’yi baştan tasarlasaydınız ilk hangi kararı verirdiniz ve neden?” Cevapları bu maddelere bağlayarak kapatın.

Alıştırmalar

1. Bir sistemin mimarisini tasarlamaya, gereksinim belirtimi tamamlanmadan neden başlamak zorunda kalabilirsiniz?
2. İnternette müzik satan ve dağıtan bir sistem için bir mimari önerin. Önerinizin temelinde hangi mimari desenler var?
3. Bir enerji şirketinin binalar, araçlar ve ekipman gibi varlıklarını izleyen, sahadaki personelin mobil cihazlarla güncelleyebildiği ve şirketin mevcut varlık veritabanlarını birleştiren bir bilgi sistemi için katmanlı bir mimari tasarlayın.

Önce birinci ve üçüncü alıştırmayı sınıfta tartışın; ikincisi ödev olabilir. İpuçları sonraki slaydın notlarında.

Alıştırmalar (devam)

4. Doğal dildeki komutları kabul edip SQL gibi bir dildeki veritabanı sorgularına çeviren bir sistemin mimarisini, dil işleme sistemlerinin genel modelini kullanarak tasarlayın.
5. Müşteriyle bağımsız çalışıp sistem mimarisini tasarlayan ayrı bir “yazılım mimarı” mesleği olmalı mı? Sistemi başka bir şirket gerçekleştirecekse böyle bir mesleği kurmanın zorlukları neler olur?

Örnek cevap ipuçları:

1. Büyük sistemlerde ana bileşenler, sistemin üst düzey özelliklerini yansıtır; gereksinimleri paydaşlarla konuşmak için bir ayrıştırma gerekir. Ayrıca işlevsel olmayan gereksinimlerin karşılanabilirliği ancak bir mimari üzerinde değerlendirilebilir.
2. Katalog ve satın alma için istemci-sunucu; sunucu tarafında katmanlı yapı; müzik dosyaları için ayrı akış sunucuları; arayüzde MVC; ödeme için hareket işleme.
3. Genel bilgi sistemi modelinin dört katmanı: mobil ve web arayüzü; kimlik doğrulama ve senkronizasyon; varlık bilgisi yönetimi ve mevcut veritabanlarıyla bütünleştirme; işlem yönetimi ve veritabanı. Çevrimdışı çalışma ve eşitleme ayrıca tartışılmalı.
4. Çevirici: sözcüksel ve sözdizimsel analiz, anlam çıkarma (sözlük, veri şeması bilgisi), SQL üretimi; yorumlayıcı: veritabanı yönetim sistemi. Belirsiz komutlar için kullanıcıya geri bildirim.
5. Zorluklar: mimar uygulama teknolojisinden kopabilir, kararların gerekçesi uygulayıcıya aktarılamayabilir, mimari ile gerçekleştirme arasındaki geri bildirim döngüsü kopar, sorumluluk paylaşımı belirsizleşir.