Tasarım ve Uygulama
2026
Bu dersin sonunda:
1 · Modellemeyi uygulamaya dökmek
Sistem modellemenin ve mimari tasarımın, nesne yönelimli bir yazılım tasarımında nasıl kullanıldığını göstermek. Örnek: kırsal hava istasyonu.
2 · Programlama kitaplarında olmayanlar
Programlama kitaplarında genellikle anlatılmayan önemli uygulama konuları: yeniden kullanım, yapılandırma yönetimi, ana-hedef geliştirme ve açık kaynak.
Geliştirdiğiniz ya da kullandığınız bir uygulamayı düşünün: Sıfırdan yazmak mı, hazır bir ürünü uyarlamak mı daha mantıklı olurdu? Neden?
Sistem bağlam modeli
Yapısal bir modeldir: geliştirilen sistemin ortamındaki diğer sistemleri gösterir. İlişkiler basit bağlantılarla çizilir.
Etkileşim modeli
Dinamik bir modeldir: sistem kullanılırken çevresiyle nasıl etkileştiğini gösterir. Çok ayrıntıya girmeyen soyut bir yaklaşım için kullanım durumu modeli kullanılır.
| Alan | Açıklama |
|---|---|
| Aktörler | Hava bilgi sistemi, hava istasyonu |
| Veri | Toplama döneminde ölçülen yer ve hava sıcaklıklarının, hava basıncının ve rüzgâr hızının en yüksek, en düşük ve ortalama değerleri; toplam yağış; beş dakikada bir örneklenen rüzgâr yönü. |
| Uyaran | Hava bilgi sistemi istasyonla bir uydu bağlantısı kurar ve verinin iletilmesini ister. |
| Tepki | Özetlenmiş veri hava bilgi sistemine gönderilir. |
| Notlar | İstasyonlardan genellikle saatte bir rapor istenir; bu sıklık istasyona göre farklı olabilir ve ileride değişebilir. |
Hava istasyonunun “Durumu bildir” ve “Yeniden yapılandır” kullanım durumlarını tablo biçiminde açıklayın.
Bu aşamada temel nesneler hakkında bazı fikirlerimiz vardır; tasarım ilerledikçe onları iyileştiririz. 1980’lerden beri önerilen üç yol:
1 · Dilbilgisi analizi
Sistemin doğal dil açıklamasında isimler nesne ve öznitelik, fiiller işlem olur (Abbott, 1983).
2 · Somut şeyler
Uygulama alanındaki şeyler (uçak), roller (yönetici), olaylar (istek), etkileşimler (toplantı), yerler (ofis), birimler (şirket) (Wirfs-Brock ve ark., 1990).
3 · Senaryo analizi
Kullanım senaryoları tek tek incelenir; her senaryo için gereken nesneler, öznitelikler ve işlemler belirlenir (Beck ve Cunningham, 1989).
Aletler bozulabilir
İstasyonlar uzak yerlerdedir; arızalar otomatik bildirilmeli. → Aletlerin doğru çalıştığını denetleyen öznitelik ve işlemler (test()).
Çok sayıda istasyon
İletişimde ayırt edilebilmeleri için her istasyonun kendi kimliği olmalı. → kimlik özniteliği.
Farklı alet türleri
İstasyonlar farklı zamanlarda kurulur; aletler farklı olabilir. → Her aletin kimliği ve bir alet bilgileri veritabanı.
Bu aşamada nesnelerin kendisine odaklanılır; nasıl gerçekleştirileceği sonraya bırakılır.
Soyut modeller yeter
Gereksinim mühendisleri, tasarımcılar ve programcılar yakın çalışıyorsa; kararlar gerçekleştirim sırasında, gayriresmî konuşmalarla verilir. Çevik geliştirmede beyaz tahtadaki taslaklar yeterli olabilir.
Ayrıntılı modeller gerekir
Plana dayalı süreçlerde ve bağlantılar dolaylıysa: sistem kurumun bir yerinde tasarlanıp başka bir yerinde gerçekleştiriliyorsa. Herkesin tasarımı aynı anlaması gerekir.
UML’de 14 diyagram türü var, ama çoğu yaygın kullanılmaz. Üretilen model sayısını en aza indirmek, tasarımın maliyetini ve süresini düşürür.
İki ve üç boyutlu şekiller için en az beş farklı şekil sınıfı içeren bir kalıtım hiyerarşisi tasarlayın.
Veri toplama alt sistemi ile hava verisini toplayan aletler arasındaki etkileşimi bir sıra diyagramıyla gösterin.
Binalardan yazılıma
Alexander (1979), bina tasarımında doğası gereği hoş ve etkili bazı ortak desenler olduğunu öne sürdü. Desen, bir problemin ve çözümünün özünün tanımıdır; çözüm farklı ortamlarda yeniden kullanılabilir.
Ayrıntılı bir belirtim değil
Desen, birikmiş bilgelik ve deneyimin tanımıdır: ortak bir probleme denenmiş bir çözüm.
“Desenler ve desen dilleri, en iyi pratikleri ve iyi tasarımları anlatmanın, deneyimi başkalarının yeniden kullanabileceği biçimde yakalamanın yoludur.” (Hillside Group)
Denenmiş çözümler
Ortak problemlere sınanmış çözümler sunar; tasarımcıların bilgisini ve deneyimini yeniden kullanmanın yoludur.
Ortak sözcük dağarcığı
Tasarımı, kullandığınız desenleri söyleyerek anlatabilirsiniz: “Burada Gözlemci kullandık.”
Kaynaklar
“Dörtlü Çete”nin (Gang of Four) 1995 tarihli kitabındaki 23 desen; Siemens’teki yazarların desen yönelimli yazılım mimarisi (POSA) serisi.
Desenler genellikle kalıtım ve çok biçimlilik gibi nesne özelliklerine dayanır; ama deneyimi bir desende toplama fikri her tür tasarıma uygulanabilir.
Algoritma: yemek tarifi
Hedefe götüren kesin adımlar dizisidir. Tarifi izleyen herkes aynı adımları aynı sırayla uygular.
1. suyu kaynat · 2. makarnayı ekle · 3. 9 dakika pişir
Desen: mimari plan
Sonucu ve özelliklerini gösterir; nasıl inşa edeceğiniz size kalır. Aynı desen iki programda farklı kodlarla gerçekleştirilir.
Bir deseni kütüphane fonksiyonu gibi kopyalayıp yapıştıramazsınız; genel fikri kendi programınıza uyarlarsınız.
Getiri: en az bağımlılık
Konu yalnızca soyut Gözlemci’yi bilir. Yeni bir görüntü ya da abone türü eklemek konuyu değiştirmez (Açık/Kapalı ilkesi). İlişkiler çalışma sırasında kurulup koparılabilir.
Bedel
Konu görüntüleri tanımadığı için görüntüye özel iyileştirmeler pratik değildir. Bir değişiklik, bazıları gereksiz bir güncelleme zinciri başlatabilir. Abonelerin hangi sırayla haber alacağı garanti edilmez.
Bugün aynı fikir olay dinleyicilerinde (event listener), yayınla-abone ol sistemlerinde ve arayüz çatılarının reaktif durum yönetiminde yaşıyor.
Ne zaman?
Karmaşık bir alt sistemin bir kısmına sade bir arayüz gerektiğinde; alt sistemi katmanlara ayırırken her katmanın girişine bir cephe koymak için.
Getiri
İstemci alt sistemin karmaşıklığından yalıtılır. Alt sistem değişince yalnızca cephe değişir; gerekirse alt sisteme doğrudan erişim de açık kalır.
Bedel
Cephe zamanla her sınıfa bağlı bir “tanrı nesnesi”ne dönüşebilir. Çok büyürse konulara göre ek cephelere bölün.
Adaptör ile karıştırmayın: Adaptör var olan bir arayüzü beklenen arayüze uyarlar ve genelde tek nesneyi sarar; Cephe ise bütün bir alt sisteme yeni ve daha basit bir arayüz tanımlar.
Ne zaman?
Karmaşık bir veri yapısını istemciden gizlemek; gezinme kodunun her yerde tekrarlanmasını önlemek; henüz bilinmeyen yapılarda da aynı kodla gezinmek istediğinizde.
Getiri
Gezinme koleksiyondan ayrı bir sorumluluk olur. Yeni koleksiyon ve yineleyici eklemek istemciyi bozmaz. Her yineleyici kendi konumunu tutar: paralel gezinme, durup sürdürme.
Bedel
Basit bir liste için gereksiz karmaşıklıktır. Bazı özel koleksiyonlarda doğrudan erişimden daha yavaş olabilir.
Aynı fikir: veritabanı imleçleri (cursor), dosyayı satır satır okumak, sayfa sayfa gelen API sonuçları.
Günlük hayattan
Giysi katmanları: Üşüyünce kazak, yağmur yağınca yağmurluk giyersiniz. Katmanlar sizin parçanız değildir; gerekince çıkarırsınız.
Getiri
Alt sınıf yazmadan davranış eklenir; katmanlar çalışma sırasında eklenip çıkarılır ve birleştirilir. Büyük bir sınıf küçük sorumluluklara bölünür.
Bedel
Yığının ortasındaki bir katmanı çıkarmak zordur. Davranış katmanların sırasına bağlı kalabilir. Katmanları kuran kod karmaşık görünebilir.
Süsleyici nesnenin dışını (kabuğunu) değiştirir; Strateji deseni ise içini, yani algoritmasını.
| Desen | Aile | Problem | Fikir | Benzetme |
|---|---|---|---|---|
| Gözlemci | Davranışsal | Bir değişiklik, önceden bilinmeyen nesneleri ilgilendiriyor | Abone listesi ve bildir() | Dergi aboneliği |
| Cephe | Yapısal | Karmaşık bir alt sistemi kullanmak zor | Tek ve sade bir giriş arayüzü | Telefonla sipariş |
| Yineleyici | Davranışsal | Farklı koleksiyonlarda aynı biçimde gezinmek | Gezinmeyi ayrı bir nesneye taşımak | Roma’yı gezmenin yolları |
| Süsleyici | Yapısal | Her birleşime alt sınıf yazmadan davranış eklemek | Aynı arayüzle sarmalamak | Giysi katmanları |
Çalıştırılabilir bileşeni yeniden kullanmak
Gerçekleştiricinin ayrıntılı kararlarına bağlı kalırsınız: kullanılan algoritmalar, arayüzdeki nesne ve türler. Bu kararlar gereksinimlerinizle çelişirse yeniden kullanım imkânsızlaşır ya da sisteme verimsizlik katar.
Deseni yeniden kullanmak
Fikri yeniden kullanırsınız; gerçekleştirimi geliştirdiğiniz sisteme göre uyarlarsınız.
Zayıf dilin yaması
Bazı desenler dilde eksik bir özelliği kapatır. Örneğin Strateji, birçok modern dilde basit bir lambda ifadesine dönüşür.
Körü körüne uygulama
Desen bir şablondur. Projeye uyarlamadan kitaptaki yapıyı harfi harfine kopyalamak verimsiz çözümler doğurur.
Gereksiz kullanım
Yeni öğrenen her yerde desen görür: “Elinde çekiç olana her şey çivi görünür.” Basit kod yeterliyse desen gereksizdir.
Önce basit çözümü yazın; desen, problem gerçekten ortaya çıktığında devreye girer.
Kullandığınız bir uygulamada aynı verinin birden çok görüntüsü var mı? Gözlemci deseniyle nasıl tasarlanırdı?
Yeniden kullanım
Modern yazılımların çoğu, var olan bileşen ya da sistemlerin yeniden kullanılmasıyla kurulur. Var olan koddan olabildiğince yararlanın.
Yapılandırma yönetimi
Geliştirme boyunca her bileşenin birçok sürümü oluşur. Bunlar izlenmezse sisteme yanlış sürümler girer.
Ana-hedef geliştirme
Üretim yazılımı genellikle geliştirildiği bilgisayarda çalışmaz: bir bilgisayarda (ana) geliştirilir, başka bir bilgisayarda (hedef) çalışır.
Sürüm yönetimi
Git (çok merkezli, çok ekipli geliştirme), Subversion. GitHub, GitLab gibi platformlar Git etrafında kapsamlı araçlar sunar.
Bütünleştirme ve derleme
Dile yerleşik araçlar ya da ayrı bir araç takımı: GNU derleme sistemi, Maven, Gradle, npm…
Sorun izleme
Bugzilla, Jira; GitHub ve GitLab’in kendi “issues” bölümleri.
Bu araçlar genellikle Eclipse ya da VS Code gibi bir tümleşik geliştirme ortamına (IDE) yerleştirilir.
Kod daha büyük bir sistemle bütünleştirildiğinde sorunlar ortaya çıkabilir. Yapılandırma yönetimi bu sorunları ele alırken nasıl yardımcı olur?
Aynı platform: Java
Hedef ortam Java Sanal Makinesidir (JVM). İlke olarak her bilgisayarda aynıdır; program bir makineden diğerine taşınabilir, aynı makinede geliştirilip sınanabilir.
Farklı platform: gömülü ve mobil
Geliştirme ve çalıştırma platformları farklıdır. İki yol var:
Derleyici ve sözdizimi güdümlü düzenleyici
Kodu oluşturmak, düzenlemek, derlemek
Hata ayıklayıcı
Dile özgü hata ayıklama sistemi
Grafik düzenleme araçları
ör. UML modellerini düzenleme
Test araçları
ör. JUnit: yeni sürümde testleri otomatik çalıştırır
Yeniden düzenleme ve görselleştirme
Refactoring ve program görselleştirme
Yapılandırma yönetimi araçları
Sürümleri yönetmek, sistemi bütünleştirip derlemek
Ayrıca: statik çözümleyiciler gibi özel araçlar (Bölüm 12) ve ekipler için değişiklik ve yapılandırma yönetimini, belki gereksinim yönetimini çalıştıran ortak bir sunucu.
Gömülü sistemde hedef genellikle tek bilgisayardır; dağıtık sistemlerde ise bir karar gerekir.
Donanım ve yazılım gereksinimleri
Belirli bir donanım mimarisi için tasarlanmış ya da başka bir yazılıma dayanan bileşen, bunu sağlayan platforma konuşlandırılmalıdır.
Erişilebilirlik gereksinimleri
Yüksek erişilebilirlik isteyen sistemlerde bileşen birden fazla platforma konuşlandırılır; biri çökerse diğeri devreye girer.
Bileşenler arası iletişim
Çok iletişim kuran bileşenler aynı ya da fiziksel olarak yakın platformlara konur; böylece gecikme azalır.
Özgür Yazılım Vakfı (FSF)
Kaynak kod mülk olmamalı; kullanıcılar onu her zaman inceleyip istedikleri gibi değiştirebilmeli.
Varsayım: kodu kullanıcılar değil, küçük bir çekirdek ekip geliştirir ve denetler.
Açık kaynak (Raymond, 2001)
İnternet üzerinden çok daha geniş bir gönüllü geliştirici topluluğu toplanır; çoğu aynı zamanda kodun kullanıcısıdır.
İlke olarak her katkıcı hata bildirebilir, düzeltebilir, yeni özellik önerebilir.
Ucuz ya da ücretsiz
Genellikle ücretsiz indirilir.
Belgelendirme ve destek isterseniz ödeme yapmanız gerekebilir; ama bu maliyet çoğunlukla düşüktür.
Çok güvenilir
Yaygın kullanılan sistemlerin, sorunları geliştiriciye bildirip yeni sürüm beklemek yerine kendisi düzelten geniş bir kullanıcı kitlesi vardır.
Hatalar, mülk yazılımda olduğundan daha hızlı bulunup onarılır.
1 · Olgun bir çözüm var mı?
Alanınızda yaygın kullanılan, bakımı süren bir açık kaynak sistem var mı?
2 · Uyumluluk ve entegrasyon
Mevcut sistemlerinizle birlikte çalışabilir mi; veri biçimleri ve arayüzler uyuşuyor mu?
3 · Lisans koşulları
GPL, LGPL, BSD, MIT: ürününüzü açmak zorunda kalır mısınız?
4 · Özelleştirme ve bakım
Ne kadar değiştirmeniz gerekecek; değişiklikleri kim sürdürecek?
5 · Ekibin deneyimi
Ekip bu teknolojiyi ve açık kaynak çalışma biçimini tanıyor mu?
Çift lisanslama
Aynı kod iki lisansla sunulur: GPL sürümü ücretsizdir; ürününü kapalı tutmak isteyen şirket ticari lisans satın alır.
Örnek: MySQL veritabanı.
Barındırılan hizmet (SaaS)
Kod açıktır; isteyen kendi sunucusuna kurar. Ama çoğu kullanıcı kurup işletmek yerine üreticinin işlettiği hizmeti kullanır ve abonelik öder.
Örnek: GitLab’ın bulut hizmeti.
Hangi model seçilirse seçilsin, başarı güçlü bir çekirdek bakım ekibine ve katkıları yöneten etkili bir sürece bağlıdır.
Kaygı: gizli bilgi
Bazı şirketler, açık kaynağın gizli iş bilgisini rakiplere açacağından çekinir.
Küçük şirket için güvence
Yazılımınızı açarsanız müşteriler, şirketiniz kapansa bile yazılımı destekleyebileceklerinden emin olur.
Kodu yayımlamak topluluk getirmez
Başarılı açık kaynak ürünlerin çoğu platform ürünüdür, uygulama değil. GitHub’da yalnızca birkaç kez indirilmiş binlerce proje var.
Ama erişim güvencesi verir
Yazılımın geleceğinden kaygılanan kullanıcılar kendi kopyalarını alır; yazılıma erişimi kaybetmezler.
Müşteriye göre yapılandırılan bir ürünü olan küçük bir şirket, sistemin yapılandırmasına katılmak isteyen büyük bir müşteri kazanmak üzere. Ürünü açık kaynak yapmak neden iyi bir fikir olabilir?
| Soru | Kavram | Akılda kalacak |
|---|---|---|
| Nasıl tasarlarız? | Nesne yönelimli tasarım süreci | Bağlam → mimari → nesneler → modeller → arayüzler; adımlar iç içe ilerler |
| Hangi nesneler? | Nesne tanımlama | Dilbilgisi çözümlemesi, somut varlıklar, senaryolar; alan bilgisi ve sezgi |
| Nesneler nasıl etkileşir? | Sıra ve durum modelleri | Sıra modeli bir senaryoyu, durum modeli bir nesnenin yaşamını anlatır |
| Bileşenler nasıl birleşir? | Arayüz belirtimi | Arayüz gerçekleştirmeden ayrılır; ekipler paralel çalışır |
| Bu problem çözüldü mü? | Tasarım desenleri | Ad, problem, çözüm, sonuçlar; üç aile; kod değil, kavram yeniden kullanılır |
| Kodu nasıl yönetiriz? | Yeniden kullanım, yapılandırma yönetimi | Önce var olanı arayın; her sürümü izleyin |
| Nerede çalışacak? | Ana-hedef geliştirme | Geliştirme ve çalıştırma platformu çoğu zaman farklıdır |
| Kodu açmalı mıyız? | Açık kaynak ve lisanslar | Lisans, ürününüzü açmak zorunda kalıp kalmayacağınızı belirler |
Şekiller 2B ve 3B olarak sınıflandırılabilir. En az beş farklı şekil sınıfı içeren bir kalıtım hiyerarşisi tasarlayın.
Hava istasyonunun veri toplama alt sistemi ile hava verisini toplayan aletler arasındaki etkileşimi sıra diyagramlarıyla gösterin.
Aşağıdaki sistemlerdeki olası nesneleri belirleyip nesne yönelimli bir tasarım geliştirin:
Yazılım Mühendisliği – OMÜ | 🏠