Dekra Projesi

7.1.2009 tarihinden itibaren Stuttgart (Almanya) şehrinde bulunan Dekra firması için J2EE danışman (freelancer) olarak işe başladım. 6 aylık proje sözleşmesi imzaladım. Dekra mühendislik hizmetleri veren bir firma. Hizmet yelpazesi otomobil vizesinden, binalarda kullanılan asansörlerin kontrolüne kadar değişik alanları kapsıyor.

 

Dekra Merkez binası (Stuttgart – Almanya)

Dekra’nın büyüklüğü hakkında fikir edinebilmeniz için firma hakkında bazı bilgiler:

  • 15.000 yakın çalışanı var.
  • 4000 den fazla mühendis Almanya çapında kontrol yapıyor.
  • Yıllık cirosu 1.5 milyar EUR civarı.
  • Almanya çapında 250 ye yakın kontrol merkezi bulunuyor.

Dekra dört hizmet biriminden oluşuyor (BU = Business UNIT):

  • BU1 – Otomotif
  • BU2 – Endüstri
  • BU3 – Qualification / Consulting
  • BU4 – International

Dekra’yı ben daha önce otomobiller için yaptıkları vize kontrollerinden tanırdım. Bunun yanısıra meydana gelen kazalarda Dekra mühendisleri hasar tespiti yapmaktalar. Projeye başladıktan sonra Dekra’nın diğer çalışma alanlarını da tanıma fırsatı buldum.

Dekra için oluşturulan altyapı tamamen J2EE tabanlı. Kontrol merkezleri ve mühendisler, kullandıkları mobil bilgisayarlar (notebook) aracılığıyla WAN (wide area network) üzerinden merkez ile bağlantı kuruyorlar ve oluşan tüm verileri merkeze aktarıyorlar. Veriler JMS (java Messaging System) üzerinden merkeze iletiliyor. Bu şekilde kullanılan komponentler hata toleransı yüksek bir altyapı meydana getiriyorlar.

Projenin ilerleyen safhalarında izlenimlerimi sizinle paylaşacağım.

Extreme Programming for Web Projects

Doug Wallace, Isobel Raggett ve Joel Aufgang tarafından kaleme alınan bu kitap, Extreme Programming tekniklerinin bir web projesinde nasıl uygulanabileceğini, bir proje menajeri perspektifinden anlatmaktadır.

Bilindiği üzere Extreme Programming (XP) server tarafında çalışan kodların implementasyonunu esnasında oluşturulmuş bir dizi yazılım tekniklerini ihtiva etmektedir. Bu sebepten dolayı XP bir web projesinin nasıl XP teknikleri kullanılarak implemente edilebileceği hakkında bilgi ihtiva etmez.  Web aplikasyon yazılımını diğer yazılım disiplinlerinden ayırt eden bazı özellikleri mevcuttur. Kitap, XP’nin bir web projesinde bu ayrıcalıkları göz önünde bulundurularak, nasıl kullanılabileceğini anlatmaktadır.

 

Bir yazılımcı olarak kitabın teknik anlatımlarla XP’nin web projelerinde nasıl uygulandığını ihtiva etmesini arzulardım. Ama ne yazik ki kitap, yazılımcılar için yazılmamış. Konu daha ziyada bir proje menajerinin perspektifinden incelenmiş.

Kitabin içeriği şöyledir:

  • 1. Bölüm: Web yazılım endüstrisi neden XP’ye ihtiyaç duymaktadır?
  • 2. Bölüm: Proje tahminleri
  • 3. Bölüm: Müşterinin güvenini kazanmak
  • 4. Bölüm: Sürüm planlaması
  • 5. Bölüm: Proje ekibi
  • 6. Bölüm: Yazılım ortamı (Development Environment)
  • 7. Bölüm: İterasyon bazında çalışmak
  • 8. Bölüm: Grafik tasarım süreci
  • 9. Bölüm: Web projelerinde XML kullanımı
  • 10. Bölüm: Web yazılım teknikleri
  • 11. Bölüm: Planlama
  • 12. Bölüm: Tasarım (Design)
  • 13. Bölüm: Yazılım (Coding)
  • 14. Bölüm: Test

 XP test güdümlü yazılım yapmaya büyük önem vermektedir. Ne yazık ki kitapta test güdümlü web yazılımının nasıl uygulandığı yer almaktadır.

 

Tavsiye edilen makeleler

 

Bu kitabı aşağıda yer alan link üzerinden satın alabilirsiniz.

CETURK Java Teknolojileri Ankara Etkinliği

3 ocak 2009 tarihinde Ankara Çankaya üniversitesinde CETURK tarafından düzenlenen Java teknolojileri seminerine konuşmacı olarak katılacağım. Apache Wicket framework hakkında bir sunum yapacağım. Bu konu hakkındaki yazımı http://www.kurumsaljava.com/2008/12/25/web-framework-gokyuzunde-yeni-bir-yildiz-wicket/ adresinden temin edebilirsiniz.

Detaylar için tıklayın.

Strategy (Strateji) Tasarım Şablonu

Bir işlemi yapabilmek için birden fazla yöntem (algoritma) mevcut olabilir. Yerine göre bir yöntem seçip, uygulamak için Strategy tasarım şablonu kullanılır. Her yöntem (algoritma) bir sınıf içinde implemente edilir.

 

Bu yazıyı PDF olarak edinebilirsiniz.

  Strategy (Strateji) Tasarım Şablonu (200,1 KiB, 9.892 yükleme)

Konuyla İlgili Kitaplar

        

Iterator (Tekrarlayıcı) Tasarım Şablonu

Iterator tasarım şablonu ile bir listede yer alan nesnelere sırayla, listenin yapısını ve çalışma tarzını bilmek zorunluluğumuz olmadan erişebilir ve bu nesneler üzerinde işlem yapabiliriz.

UML diagramında Takim interface sınıfını implemente eden iki basketbol takımı yer almaktadır: Efes Pilsen ve Fenerbahçe Ülker Basketbol takımları. Ligde oynayan her takım için Takim interface sınıfını implemente eden bir sınıf oluşturulabilir. Takım içinde yer alan oyuncuları tutmak için her sınıf kendi bünyesinde bir liste oluşturabilir. Takim interface sınıfı, bu listenin yapısı hakkında bir zorunluluk getirmediği için her takım kendi listesini istediği yapıda oluşturabilir. EfesPilsen sınıfını incelediğimiz zaman, oyuncuların bir ArrayList içinde tutulduğunu görmekteyiz.

Bu yazıyı PDF olarak edinebilirsiniz.

  Iterator (Tekrarlayıcı) Tasarım Şablonu (207,4 KiB, 10.612 yükleme)

Konuyla İlgili Kitaplar

        

Agile Software Development

Büyük usta Robert Cecil Martin tarafından kaleme alınan Agile Software Development isimli kitapta çevik yazılım ile ilgili prensipler ve pratikler yer almaktadır. Özellikle tasarım prensiplerinin detaylı anlatım bulduğu kitabın, her yazılım mühendisi tarafından mutlaka okunması gereken bir kaynak kitap olarak görebiliriz.

 

Kitabın içeriği özetle şu şekildedir:

  • Çevik pratikler
  • Extreme Programming’e giriş
  • Planlama / Test / Refactoring (Yeniden yapılandırma)
  • Çevik tasarım
  • Tasarım prensipleri
  • Paket tasarım prensipleri
  • Test Driven Development (TDD) örneği
  • Tasarım şablonları kullanımı

Bu kitabı yazılımcı olarak okumanız şiddetle tavsiye edilmektedir!

Çevik Süreç Nedir?

Yazılım sektörü yıllardan beri kan kaybediyor. Ama artık taze kan bulundu ve hastalığın tedavisi kolaylaştı. Çözüm çevik süreçler!

Günümüze kadar uzanan süreçte yazılım sektöründe yapılan projeler nereye varacağı belli bile olmayan büyük maceralar haline gelmiştir. Bunun başlıca sebebi kullanılan yazılım yöntemlerinin gereksinimlere cevap verecek yapıda olmamasıdır. Çevik süreçler bu sorunu çözecek nitelikte.

Bu bölümde

  • yazılım yaparken hedefin ne olduğunu,
  • çevikliğin ve çevik sürecin ne olduğunu,
  • çevik manifesto ve prensiplerinin ne anlama geldiğini,
  • çevik sürecin diğer yazılım metotlarına kıyasla hangi farklılıkları beraberinde getirdiğini,
  • hangi çevik süreç türlerinin mevcut olduğunu,
  • bir çevik süreç olan Extreme Programming’in ne olduğunu,
  • Extreme Programming’in hangi değer, prensip ve teknikler üzerine kurulu olduğunu

yakından inceleyeceğiz.

Bu yazıyı PDF olarak edinebilirsiniz.

  Çevik Süreç Nedir? (219,4 KiB, 13.137 yükleme)

Data Access Object (DAO) Tasarım Şablonu

Birçok programın var olma nedeni veriler üzerinde işlem yapmak,verileri bilgibankalarında depolamak ve bu verileri tekrar edinmektir. Bu böyle olunca, verilerin program tarafından nasıl bilgibankalarına konulduğu ve tekrar edinildiği önem kazanmaktadır. Data Access Objects (DAO) tasarım şablonu ile, kullanılan veritabanına erişim ve veri depolama-edinme işlemi daha soyutlaştırılarak, diğer katmanların veritabanına olan bağımlılıkları azaltılır. DAO ile diğer katmanlar etkilenmeden veritabanı ve bilgibankası değiştirilebilir. Daha öncede belirttiğim gibi, amacımız birbirini kullanan ama birbirine bağımlılıkları çok az olan katmanlar oluşturmak ve gerekli olduğu zaman bir katmanı, diğer katmanlar etkilenmeden değiştirebilmek olmalıdır. Katmanlar arası bağımlılık interface sınıfları üzerinden olduğu sürece bu amacımıza her zaman ulaşabiliriz.

Bu yazıyı PDF olarak edinebilirsiniz.

  Data Access Object (DAO) Tasarım Şablonu (182,1 KiB, 21.222 yükleme)

Konuyla İlgili Kitaplar

      

Yazılım Test Türleri

Yazılım sürecinde oluşturulan sistemin kalite kontrolü yazılım testleri ile yapılır. Bu bölümde yazılım testlerin nasıl hazırlandığını yakından inceleyeceğiz. Bir sonraki bölümünde yer alan test güdümlü yazılımı (Test Driven Development – TDD) uygulayabilmek için yazılım test konseptlerinin bilinmesi gerekmektedir. Java tabanlı sistemlerde testler JUnit çatısı kullanılarak hazırlanır.

Değişik türde yazılım testleri oluşturmak mümkündür. Bunlar:

  • Birim testleri (Unit Testing)
  • Entegrasyon testleri (Integration testing)
  • Arayüz (interface) testleri (Functional Interface Testing)
  • Regresyon testleri (Regression Testing)
  • Akseptans testleri (Acceptance Testing)
  • Sistem testleri (System Testing)
  • Stres testleri (Stress Testing)
  • Performans testleri (Performance Testing)
Bu yazıyı PDF olarak edinebilirsiniz.

  Unit Testing Konseptleri (329,4 KiB, 14.448 yükleme)

Konuyla İlgili Kitaplar

     

Web Aplikasyonlarında Yüksek Performans için Caching Mekanizmaları

Facebook gibi, aynı anda binlerce insanın kullandığı web platformlarının temel sıkıntısı
kullanılan kaynakların (hardware, software) yetersiz kalmasıdır. Kullanıcı sayısı arttıkça
sistem kaynaklarının da artırılması gerekmektedir. Bu genelde bilgibankası için yeni server
sistemlerini takviyesiyle gerçekleşir ya da mevcut server sistemlerinin hafıza (ram) alanlarının
genişletilmesiyle. Kullanıcı sayısı çoğu platformlarda her gün arttığı için, kaynak kapasitenin
artırılması da kaçınılmazdır. Web girişimciliğinde alt yapı giderlerinin önemli bir rol
oynadığını düşünecek olursak, her kaynak kapasite artırımı, girişimcinin sırtına ek gider
bindirecektir.

Yüksek trafiğe sahip web platformlarının en büyük sıkıntısı, web server sistemleri üzerinde
çalışan program ile bilgibankası arasındaki veri trafiğinin zaman içinde dar boğaza dönüşmesi
ve yetersiz kalmasıdır. Bu sorunu çözmek için sisteme yeni bilgibankası serverleri eklenir ve
veriler replikasyon (replication – kopya etme) mekanizmaları kullanılarak sisteme ait tüm
bilgibankası serverlerinde senkron tutulur. Bu sistemin bakımını ve geliştirilmesini
zorlaştırabilecek bir gelişme olarak değerlendirilebilir.
Bu yazıda caching (ön belleğe alma) mekanizmaları kullanılarak dar boğaza dönen
bilgibankalarının kapasite takviyesine gerek kalmadan nasıl rahata kavuşturulabileceğini
yakından inceleyeceğiz.

Bu yazıyı PDF olarak edinebilirsiniz.

  Web Aplikasyonlarında Yüksek Performans için Caching Mekanizmaları (512,0 KiB, 13.809 yükleme)

Singleton (Tekillik) Tasarım Şablonu

Bazı şartlar altında bir sınıftan sadece bir nesnenin oluşturulması ve oluşturulan bu nesnenin
tüm sistemde kullanılması gerekebilir. Örneğin bilgibankası için bir connection pool
(bilgibankası bağlantı havuzu) sadece bir defa oluşturulmalı ve kullanılmalıdır. Bu durumda
Singleton tasarım şablonu kullanılarak, bir sınıftan sadece bir nesnenin oluşturulması
sağlanabilir.

Bu yazıyı PDF olarak edinebilirsiniz.

  Singleton (Tekillik) Tasarım Şablonu (136,1 KiB, 17.844 yükleme)

Konuyla İlgili Kitaplar

      

Sürekli Entegrasyon (Continuous Integration)

Sürekli entegrasyon (Continuous Integration = CI) kod üzerinde yapılan her değişikliğin ardından, tüm sistemin çalışır durumda olduğunu, yapılan değişikliğin sistemin bazı bölümlerinde kırılmalara yol açmadığını tespit etmek için kullanılan yöntemdir. Kırılmaları tespit edebilmek için testlere (JUnit) ihtiyaç duyulmaktadır. Bu testler, yapılan değişikliğin neticesi olarak yeni bir yapı (build) hazırlandıktan sonra otomatik olarak çalıştırılır. Yapılan değişiklik yeni yapının bir parçası olduğu için, testlerde oluşan hatalar, yapılan değişikliğin sistemi kırdığı anlamına gelmektedir. Bu durumdan tüm programcılar haberdar edilerek, hatanın bir an önce giderilmesi ve testlerin her zaman olumlu sonuç vermesi sağlanır. Sürekli entegrasyon ile programcılar tarafından kod üzerinde yapılan çalışmalar neticesinde her zaman çalışır bir sürümün oluşması sağlanmış olur.

Bu yazıyı PDF olarak edinebilirsiniz.

  Sürekli Entegrasyon (Continuous Integration) (479,7 KiB, 5.816 hits)
You need to be a registered user to download this file.

Test Güdümlü Yazılım – Test Driven Development (TDD)

 

Günümüzde kurumsal projelerin büyük bir bölümü geleneksel yazılım  metotları ile gerçekleştirilmektedir. Müşteri gereksinimleri en son detayına kadar kağıda döküldükten sonra, programcılar dokumente edilen gereksinimler doğrultusunda yazılımı gerçekleştirmektedirler. Eğer proje bütçesi yeterli ise, yazılım süreci sona erdikten sonra testler hazırlanarak, yazılım sistemi test edilmektedir. çoğu zaman hiçbir unit testin yapılmadığı sistemlerin firmalar tarafından kritik iş alanlarında kullanıldığını görmek mümkündür. Bu tür yazılım sistemlerinde oluşan hatalar (Bug)  firmanın sunduğu hizmetleri kısıtlamakta ve en kötü ihtimalle firmanın para kaybetmesine sebep olmaktadır.

Geleneksel tarzda oluşturulan yazılım sistemlerinde oluşan hataları gidermek çok pahalıya mal olabilmektedir, çünkü yazılım bittikten sonra tespit edilen hatalar yazılım sistemindeki tasarım açıklarını gözler önüne serebilir ve bu gibi kardinal hataların ortadan kaldırılması ya imkansız yada çok zor olabilir. Bunun yanı sıra yazılım sona erdikten sonra oluşturulan testlerin test kapsama alanı geniş olmadığı için kodun bazı bölümleri test edilememekte ve böylece hata tespiti zorlaşmaktadır. Bu şekilde yazılım esnasında ortaya çıkmayan hatalar, daha sonra sistem kullanıcıları tarafından keşfedilmektedirler. Bu aşamada geç kalınmıştır: ya sistem çalışmaz durumdadır, yada sistem kullanıcısı istediği işlemi doğru olarak gerçekleştirememiştir. Durumu kısaca şöyle özetleyebiliriz: “yazılım sistemi müşterinin gereksinimlerini tatmin edecek kaliteye sahip değildir”.

Ne yazık ki birçok firma için kullandıkları yazılım sistemlerindeki kalite problemleri firmaya zarar verici durumdadır. Bu kalite problemleri bir taraftan oluşan sistem hataları, diğer taraftan kodun bakımı ve geliştirilmesinin zor olmasından kaynaklanmaktadır. Oluşan sistem hataları  firmanın giderlerini artırmakta ve yazılım sisteminin istikrarsız ve güvenilmez olmasına sebep vermektedir. Bu sorunların temelinde test konseptlerinin bir yazılım sistemi için hayat sigortası olduğunun anlaşılamamış olması yatmaktadır.
 

Bu yazıyı PDF olarak edinebilirsiniz.

  Test Güdümlü Yazılım - Test Driven Development (TDD) (416,9 KiB, 10.436 yükleme)

Extreme Programming Nedir?

En popüler çevik süreçlerden ( Agile Process) birisi XP olarak bilinen Extreme Programming’dir. Kent Beck ve arkadaşları tarafından 1996 yılında Chrysler firmasında yapılan bir proje bünyesinde oluşan XP, ihtiva ettiği basit ama bir o kadar etkili yöntemlerle yazılım sektöründe yeni bir rüzgarın esmesini sağlamıştır.

XP ile oluşturulan çevik süreçte müşteri ve gereksinimleri merkezi bir rol oynamaktadır. Yazılım esnasında XP ile tam belirli olmayan ve çabuk değişikliğe uğrayan müşteri gereksinimlerine ayak uydurulabilir. Bu konvensiyonel yazılım metodlarda mümkün değildir, çünkü proje öncesi müşteri gereksinimleri en son detayına kadar kağıda dokülmüştür. Oluşan bir dokumentasyon baz alınarak, yazılım gerçekleştirilir. Proje ilerledikçe müşteri tarafından yapılması istenen değişikliklerin maliyeti çok yüksek olacaktır, çünkü mevcut yapı (tasarım – design) istenilen değişiklerin yapılmasını engelleyebilir yada yeni bir yapılanmaya gidilmesi gerekebilir. XP, kullanıldığı projelerde formalite ve bürokrasinin mümkün en az seviyeye çekilmesine önem verir. Çevik olabilmek için az yükle yola çıkılması gerekmektedir. Bu yüzden proje öncesi geniş çapta tasarım ve dokumentasyon oluşturulmasi izin verilmez. Bu kesinlikle dokümentasyon ve tasarım oluşturulmadan çalışıldığı anlamına gelmez!

XP Değerleri

XP dört değer üzerine kuruludur: Basitlik (Simplicity), İletişim (Communication), Geridönüm (Feedback) ve Cesaret (Courage).

XP’nin özü bu dört değer içinde yatmaktadır. Bu değerler yaşandığı taktirde XP ögrenimi ve kullanımı kolaylaşır. Bu değerlerin geçerlilik bulmadığı ortamlarda XP’nin uygulandığı söylenemez. XP ile verimli bir çevik süreç oluşturabilmek için bu değerlerin hepsinin kabul görmesi ve uygulanması gerekmektedir.

Bu değerlerin ne anlama geldiğini yakından inceliyelim. XP basit yöntemler aracılığıyla sonuca ulaşmak ister, çünkü sadece bu şekilde hızlı ve düşük maliyetli projeler gerçekleştirilebilir. Bunun yanısıra basit çözümlerle oluşturulan programın bakımı ve geliştirilmesi kolaydır. Basit çözümler kolay anlatılır ve adapte edilir. Bu zaman kazanılması anlamına gelmektedir.

Yazılımda en önemli konulardan birisi kalite kontrolüdür. XP projelerinde kalite kontrolü geridönüm (feedback) üzerinden sağlanır. Programcılar yazdıkları testlerden geridönüm alarak kaliteyi sağlarlar. Kısa zamanlarla yeni sürüm oluşturularak müşteri ve kullanıcılardan geridönüm aracılığıyla programın gereksinimleri tatmin edip, etmedigi kontrol edilir. Yazılım esnasında sürekli entegrasyon yapılarak, programın en son durumu hakkında geridönüm sağlanır. XP’nin uygulanabilmesi için değişik katmanlarda geridönüm mekanizmalarının oluşturulması gerekmektedir. İnsanlar için su ne ise, XP için geridönüm odur.

Tüm proje çalışanlarının sürekli olarak aralarında iletişim kurmaları gerekmektedir. Bireyler arası yüz yüze görüşmeler büyük önem teşkil etmektedir. Sadece bu sayede sağlıklı bilgi transferi gerçekleşebilir. Böylece yanlış anlaşılmalar ve bilinmeyenler ortadan kaldırılır. Eğer takım içinde iletişim ve interaksiyon güçlü ise, dokümentasyon oluşturma ve kullanma gereksiz hale gelebilir. Bu zaman kaybını önler. Dokümentasyon yazılımı ve kullanımı başka sebeplerden dolayı gerekli olabilir, ama projenin başarısı için dokümentasyon öncelikli rol oynamamaktadır.

Basit çözümler, geridönüm ve iletişim için cesaret gereklidir. Bu saydığımız değerler bireyler arası interaksiyonu ve iletişimi artıracağı için, bireylerin kendi iç dünyalarını terk edip, takımın bir parçası olmalarını kolaylaştırırlar. Bu kişisel gelişmeyi sağlar ve temelinde kişisel cesaret yatar.

XP Prensipleri

XP değerlerinden yola çıkarak onbeş XP prensibi oluşturulmuştur. Bunlar:

Rapid Feedback

Hızlı geridönüm

Sık ve hızlı geridönüm edinmek, projenin gidişatını olumlu etkiler. Geridönüm sayesinde yanlış anlaşılmalar ve hatalar ortadan kaldırılır.

Assume Simplicity

Basitliği tercih etmek

Basit çözümler kolay implemente edilir ve kısa zamanda oluşturulur. Bu geridönümün de hızlı bir şekilde gerçekleşmesini sağlar. Basit çözümlerin kavranması ve anlatılması daha kolaydır. XP programcılardan o anki gereksinimi tatmin etmek için basit çözümü bekler. Programcı gelecekte oluşabilecek eklemeleri ve değişiklikleri düşünmemeli, sadece ve sadece kendisinden o an için bekleneni en basit haliyle implement etmelidir.

Incremental Change

İnkrementel değişiklik

Basit çözümler uygulasak bile, yazılım sistemleri zaman içinde karmaşık bir yapıya dönüşebilir. Yapılan en ufak bir değişiklik bile, sistemin düşünmediğimiz bir bölümü üzerinde hata oluşmasına sebep verebilir. Oluşabilecek bu hataları kontrol altında tutabilmek için değişikliklerin ufak çapta olması gerekmektedir. Büyük değişiklikler beraberinde büyük sorunları getirebilir. Bu sebepten dolayı değişikliklerin ufak çapta ve sıklıkla yapılması gerekmektedir.

Embracing Change

Değişimi istemek

İlerliyebilmek için kendimize bir yön tayin etmemiz ve yeniliklere açık olmamız gerekiyor. Yeniliklere açık olmak cesaret gerektirir. Bilinmeyenle ugraşmak, rahatsız edici olabilir, ama başarıyı elde edebilmek için değişimi istemek gerekir.

Quality Work

Kaliteli iş

XP projelerinde kaliteli işin ortaya konabileceği bir ortamın oluşturulması geremektedir. Hiçbir programcı hatalı program yazmak istemez. Çalışma ortamınında etkisiyle yüksek kalitede yazılım yapmak  hem programcının özgüvenini artırır, hemde müşteriyi tatmin edici ürünlerin ortaya konmasını sağlar.

Teach Learning

Öğrenmeyi öğret

XP programcı takımlarında tertipcilik ve kıdem farkı yoktur. Tecrübeli programcılar bilgilerini daha az tecrübeli programcılarla paylaşarak, hem bilginin çoğalmasını sağlarlar, hemde takım arkadaşları ile teknik olarak aynı seviyeye gelirler. Programcılara komutlar vererek iş yaptırmak yerine, kendiliğinden bazı şeyleri öğrenerek, görevlerini yerine getirmeleri sağlanmalıdır.

Small Initial Investment

Az baslangıç yatırımı

XP en modern ve pahalı araç gereçlerle projeye başlanmasını beklemez. Başlangıç giderleri ne kadar düşük tutulabilirse, projenin iptali durumunda kayıplar o oranda az olacaktır. Başlangıçta tüm takımın dar bir finansman korsasını giymesi sağlanarak, proje için daha önemli görevlere odaklanmaları sağlanır. Bunu bir örnekle açıklıyabiliriz. Proje başlangıcında en son Oracle bilgibankası ve kullanıcı araçları (Toad gibi bir client program) satın alınarak, tüm ekibe bu bilgibankasını ve araçları nasıl kullanacaklarına dair seminer verilebilir. Bu çok masraflı ve bir o kadarda gereksiz bir şeydir. Projeye open source ve ücretsiz olan HSQL yada PostgreSQL bilgibankası ile başlanabilir. Programcı ekip böylece ne bir hafta tanımadıkları bir ürün için harcamış olurlar, ne de büyük masraflar yapılarak şu an için gerek olmayan bir altyapı komponenti satın alınmış olur. Gerekli araçlar zamanı geldiğinde edinilmelidir.

Play to win

Kazanmak için oyna

XP takımları kazanmak için oynar. Her zaman gözlerinin önünde nihayi sonuç vardır: programı tamamlamak ve müşteriye teslim etmek. XP programcı takıma tünelin sonundaki ışığı görmek için gerekli tüm imkanları sunar.

Concrete Experiments

Somut denemeler

Verdiğimiz kararların sonuçlarını kontrol edebilmek için denemeler yaparız, çünkü alınan kararlar her zaman doğru olmayabilir. Bir kontrol mekanizmasına ihtiyacımız  olduğu belli. Bu da somut denemeler aracılığıyla nerede olduğumuzu testpit etmekdir. Bu somut denemeler yazılım sistemleri içinde geçerlidir. Örneğin testler hazırlıyarak, oluşturuduğumuz mimari ve tasarımı kontrol ederiz.

Open, honest Communication

Açık ve samimi komunikasyon

Projenin başarılı olabilmesi için bireyler arasında açık ve samimi türde bir komuniksyonun olması gerekmektedir. Birçok projede bu böyle değildir. Çogu zaman bireylerin korkuları, deneyimsiz olmaları yada kendilerini çok beğenmeleri ve diğerlerini kendilerinden alt safhada görmeleri, açık ve samimi bir komunikasyon ortamının oluşmasını engeller.

Work with people’s instincs, not against them

Takımın içgüdülerini kullan, onlara karşı koyma

Bireysel içgüdü yanısıra, bireylerin oluşturdugu takımların da içgüdüsü vardır. Eger takım birşeylerin doğru gitmediği hissine sahipse ve bunu dile getiriyorsa, o zaman birşeyler yolunda gitmiyor demektir. Takımın içgüdüsüne kulak verilmelidir. Bunun göz ardı edilmesi, proje için olumsuz sonuçlar doğurabilir.

Accepted Responsibility

Sorumluluk üstlenmek

Sorumluluk birilerine verilmemeli, bireyler kendileri sorumluluk üstlenmeliler. Eğer bir bireye ya da bir takıma yapılması zor bir projenin sorumluluğu yüklenirse, bu birey ya da takım için motivasyonun düşmesini ve kaybetme korkusunun pekişmesini hızlandırır. Eğer bireyler ya da takımlar kendi sorumluluklarını kendileri seçerlerse, hem yaptıkları işte kendilerini iyi hissederler, hem de yüksek motivasyon ile üstlendikleri işi başarıyla tamamlarlar.

Local Adaptations

Sürecin ortam şartlarına adapte edilmesi

Büyük bir ihtimalle her takımın XP’yi Kent Beck’in anlattiğı tarzda harfiyen ugulaması mümkün değildir. Atalarımızında dediği gibi her yiğidin yogurt yeyiş tarzı başkadır. Amaç XP’yi harfiyen uygulamak değildir, amaç kısa bir zamanda projeyi başarılı bir sonuca ulaştırmaktır. Eğer proje XP’de yapılacak modifikasyonlarla başarıya ulaşacaksa, o zaman süreç üzerinde bu modifikasyonlar yapılmalı ve uygulanmalıdır. Bunda bir sakınca yoktur.

Travel light

Az yükle yolculuk yapmak

Projede hızlı ilerleyebilmek için fazla bir yükle yola çıkılmaması gerekmektedir. Beraber çalışmayı kolaylaştırmak için kullanımı kolay araç ve gereçler seçilmelidir. Formalitelerden uzak durulmalıdır.

Honest Measurement

Doğru ölçüm

Proje gidişatını kontrol edebilmek için değişik türde ölçümlerin yapılması gerekmektedir. Örneğin hazırlanan unit testleri ile sınıfların işlevleri kontrol edilir. Yapılan ölçümler doğru ve samimi yapıldıği taktirde kontrol mekanizması olarak kullanılan ölçümlerin bir anlamı vardır. Programcılar tarafından samimi ve doğru yapılmayan ölçümler projenin gidişatını olumsuz yönde etkiler.

XP Teknikleri (XP Practices)

Dört XP değer ve onbeş XP prensibi ondört XP tekniği ile desteklenmektedir. XP teknikleri programcıların XP değer ve prensiplerini uygulamada yardımcı olur. Kent Beck tarafından hazırlanan ilk XP versiyonunda oniki teknik yeralmaktaydı. Diğer çevik süreçlerin de etkisiyle Standup-Meeting’ler ve retrospektif toplantılar XP teknikleri arasına katıldı.

Bunlar:

On-site Customer

Programcıya yakın müşteri olarak tercüme edilebilir.

XP projeleri müşteri gereksinimlerine odaklı ilerler. Bu yüzden müşteri ve sistem kullanıcılarının projeye dahil edilmeleri gerekmektedir. Müşteri gereksinimlerini ekibe bildirir. Programacıların implementasyonu gerçekleştirebilmesi için müşteri tarafından dile getirilen gereksinimleri anlamaları gerekmektedir. Yanlış anlaşılmaları ve hataları gidermek için programcıların müşteri ve sistem kullanıcıları ile diyalog halinde olabilmesi gerekmektedir. Bu sebepten dolayı müşteri veya sistem kullanıcılarının programcıların erişebileceği bir uzaklıkta olmaları gerekir. Tipik XP projelerinde müşteri ve programcılar aynı odada beraber çalışırlar. Müşteri ekibin sorularını zaman kaybı olmadan cevaplar ve projenin ilerlemesine katkıda bulunur.

Standup-Meeting

Ayakta toplantı

Proje çalışanlari her gün 15 dakikayı aşmayan ve ayakta yapılan toplantılarda biraraya gelirler. Bu toplantının amacı, projenin gidişatı hakkında bilgi alışverişinde bulunmaktır.

Planning Game

Planlama oyunu

XP projeleri iteratif ve inkrementel yol alır. Bir sonraki iterasyonda yapılması gereken işleri planlama oyununda görüşülür ve sürüm ve iterasyonun içeriği tespit edilir. Planlama oyununa müşteri, kullanıcılar ve programcılar  katılır. Müşteri ve kullanıcılar daha önce kullanıcı hikayesine (user story) dönüştürdükleri isteklerine öncelik sırası verirler. Programcılar her kullanıcı hikayesi için gerekli zamanı tahmin ederler. Kullanıcı hikayelerinin öncelik sırası bu tahmine bağımlı olarak değişebilir. Planlama oyunlarında sürüm ve iterasyon planları oluşur.

Short Releases

Kısa aralıklarla yeni sürüm

XP projelerinde yeni implemente edilen ve değişikliğe uğrayan komponentler yeni sürümler oluşturularak müşteri ve kullanıcının beğenisine sunulur. Bu sayede hem müşteriler çalışır durumda olan programdan faydalanabilir hem de yeni sürümü inceliyerek, gereksinimleri ile örtüşüp, örtüşmediğini kontrol edebilirler. Eğer yeni sürüm müşteriyi tatmin edecek durumda değilse, gereksinimler değişikliğe ugrayabilir. Bu değişiklikler bir sonraki iterasyonda göz önünde bulundurularak, müşteri istekleri ile yüksek derecede örtüşen bir programın oluşturulması sağlanır.

Retrospective

Geriye  bakış

Proje çalışanları düzenli aralıklarla geriye bakarak, meydana gelen sorunları gözden geçirirler. Buradaki amaç gelecekte bu sorunların tekrarını önlemektir. Geriye bakış bir ila altıaylık zaman birimleri için tüm proje çalışanları yada seçilen bireyler tarafından yapılır. Geriye bakış toplantıları yarım gün ila üç gün arasında sürebilir.

Metaphor

Mecaz

XP projelerinde hazırlanan program için bir veya birden fazla, programın nasıl bir işlevi olacağını ekibin gözünde canlandırmalarını saglıyacak mecazi isim, öğe yada resimler kullanılır. Bunlar proje çalışanlarının ortak bir payda da buluşarak, ne yapılması gerektiği hakkında bir fikir sahibi olmalarını kolaylaştırır. Örneğin bir shop sistemi yazılımı yapılacak. Burada metaphor olarak alışveriş sepeti kullanılabilir. Alışveriş sepetini duyan her programcının aklında, bir shop sisteminin programlanması gerektiği fikri doğar.

Collective Ownership

Ortak sorumluluk

XP projelerinde programcılar ortak sorumluluk taşırlar. Bu her kod parçasının herhangi bir programcı tarafından gerekli durumlarla değiştirilebileceği anlamına gelir. Böylece yapılması gereken işler aksamaz, çünkü belli kod bölümlerinden belli programcılar sorunlu değildir. Aksine her programcı programın her bölümü üzerinde çalışma hakkına sahiptir. Bir programcının işe gelmemesi durumunda, başka bir programcı kolaylıkla onun görevlerini üstlenebilir.

Continuous Integration

Sürekli entegrasyon

Sistem değişiklikleri ve yeni komponentler hemen sisteme entegre edilerek test edilir. Sürekli entegrasyon sayesinde yapılan tüm değişiklikler her programcının sistem üzerinde yapılan değişiklikleri görmesini sağlar. Ayrıca sistem entegrasyonu için gerekli zaman azaltılır, çünkü oluşabilecek hatalar erken teşhis edilerek, ortadan kaldırılır.

Coding Standards

Kod standartları

Programcılar tarafından aynı kalitede kod yazılımı yapılabilmesi için, kod yazarken kullanılacak kuralların oluşturulması gerekmektedir. Kodun nasıl formatlanacağı, sınıfların, metot isimlerinin ve değişkenlerin nasıl isimlendirileceği kod standartlarında yeralir.

Sustainable Pace

Kalıcı tempo

XP projelerinde programcılar haftalık belirli mesai saatlerini aşmazlar. Gereğinden fazla çalıştırılan ve yorulan bir programcıdan verimli iş yapması beklenemez. Programcıların motivasyonun ve çalışma enerjilerinin yüksek olması için günde sekiz saatten fazla çalışmalarına izin verilmemelidir. Bazen fazla mesai saatlerine ihtiyaç olabilir. Eğer durum devamlı böyle ise, bu proje gidişatında bazı olumsuzlukların göstergesi olabilir.

Testing

Test etmek

Oluşturulan programların kalite kontrolünden geçmesi gerekmektedir. Bu yazılım esnasında oluşturulan testlerle yapılır. Programcılar komponentler için unit testleri hazırlar. Sınıf bazında yapılan bu testlerle komponentlerin işlevleri kontrol edilir. Müşteri gereksinimlerini test etmek için akseptans testleri hazırlanır. Komponentlerin entegrasyonunu test etmek için entegrasyon testleri hazırlanır.

Simple Design

Sade tasarım

Programcılar üstlendikleri görevleri (task) en basit haliyle implemente ederler. Bu programın basit bir yapıda kalmasını ve ilerde değiştirilebilir ve genişletilebilir olmasını sağlar. Sade bir tasarım yazılım sisteminin kompleks bir yapıda olmasını önler. Bunun yanısıra basit tasarımlar daha kolay ve daha hızlı implemente edilebilir. Basit bir implementasyonu anlamak ve anlatmak daha kolaydır.

Refactoring

Yeniden yapılandırma

Tasarım hataları yazılım sisteminin daha ilerde tamir edilemiyecek bir hale dönüşmesine sebep verebilir. Bu yüzden bu hatalar hemen giderilir. Bu yeniden yapılandırma işlemine refactoring ismi verilir. Hazırlanan unit testleri ile yapılan değişikliklerin yan etkileri kontrol edilir. Bu açıdan bakıldığında unit testi olmayan bir sistem üzerinde yeniden yapılandırma işlemi hemen hemen mümkün değildir, çünkü değişikliklerin doğurduğu yan etkileri tespit etme mekanizması bulunmamaktadır.

Pair Programming

Eşli programlama

XP projelerinde iki programcı aynı bilgisayarda çalışır. Bu sayede programcıların kısa bir zaman içinde aynı seviyeye gelmesi sağlanır. Ayrıca bu kalitenin yükselmesini sağlar.

XP Rolleri

Bir çevik projede ekip çalışanlarının sorumluluk alanlarını tanımlamak için roller tayin edilir. Her rol beraberinde bazı sorumluluklar ve tanımlanmış haklar getirir. Bu roller statik değildir. Ekip içinde değişik kişilere değişik roller verilebilir ve daha sonra rol değişikliği yapılabilir. Proje gereksinimleri doğrultusunda yeni rollerin oluşturulması mümkündür.

Müşteri (Customer)

Projenin var olma sebebi müşteridir. Müşteri ihtiyaç duyduğu ve gereksimlerine cevap verebilecek bir yazılım sistemi için yatırım yapan kişidir. XP projelerinde şu atasözümüz geçerlidir: “parayı veren düdüğü çalar!”.

Proje bünyesinde ne programlanması gerektiğini müşteri tayin eder. Müşteri yapılması gerekenleri kullanıcı hikayeleri (user story) oluşturarak ifade eder. Programcılar müşteriye bu süreçte yardımcı olurlar. Ama kullanıcı hikayelerinin oluşturulma sorumluluğu büyük ölçüde müştiriye aittir. Her kullanıcı hikayesi yazılım sisteminin bir özelliğini tanımlar. Programcıların implementasyonu gerçekleltirebilmeleri için kullanıcı hikayesini anlayabilmeleri gerekmekedir. Sadece bu durumda implementasyon süreci için bir tahminde bulunabilirler. Ayrıca oluşturulan kullanıcı hikayelerinin test edilebilir yapıda olması gerekmektedir.

Müşteri çalışma alanı (domain knowledge) hakkında bilgiye sahip olan kişidir. Programcılar müşteriye karşılaştıkları sorunları çözmek için sorular sorabilirler. Bu soruların cevabını en iyi verebilecek şahıs müşteridir.

Hangi kullanıcı hikayelerinin implemente edileceğine müşteri karar verir. Bu konuda müşteriye herhangi bir sınırlama getirilmez. Müşteri seçer ve programcılar implemente eder.

İmplemente edilen kullanıcı hikayelerini kontrol etmek amacıyla müşteri akseptans testleri tanımlar. Bu testler programcı yada testçi tarafından implemente edilir. Akseptans testleri kullanıcı hikayesini doğru implemente edilip, edilmediğini kontrol edici bir mekanızmadır.

Programcı

Sistem analizi, tasarım, test ve implementasyon programcılar tarafından yapılır.

Müşteri tarafından hazırlanan kullanıcı hikayelerinin implementasyon süresi programcılar tarafından tahmin edilir. Bu programcıların XP projelerinde proje planlama sürecine dahil edildikleri anlamına gelmektedir. Geleneksel projelerde bu tahminleri teknik bilgiye sahip olmayan yöneticiler yapmak zorundadır. Bu yüzden bu tahminler genelde gerçekleri yansıtmaz.

Her programcı test güdümlü (TDD – Test Driven Development) ve bir takım arkadaşıyla beraber çalışır. Pair programming olarak bilinen, iki programcının birlikte yazılım yapması, kısa zamanda kod hakkındakı bilginin tüm programcılar tarafından paylaşılmasını kolaylaştırır. Ayrıca pair programming programcılar arasında iletişimi ve takım içinde çalışabilme özelliğini artırır. Test güdümlü çalışmak bakımı ve geliştirilmesi kolay kodun oluşmasını sağlar. XP projelerinde programcılar herhangi bir satır kod yazmadan önce gerekli test sınıflarını oluşturarak implementasyona başlarlar.

Programcılar oluşturdukları testler yardımıyla hergün bir veya birden fazla şekilde modül entegrasyonu gerçekleştirirler. Sürekli entegrasyon programcılar tarafından oluşturulan modülleri entegre eden bir süreçtir. Her programcı bu süreçten geridönüm sağlıyarak, kendi yaptıklarının ne derecede sisteme entegre olduğunu ölçebilir.

Proje Menajeri

Proje menajeri müşteri ve programcıları bir araya getirir. Onların beraber çalışabilecekleri ortamların oluşmasını sağlar. XP proje menajeri tek başına proje planlamasından sorumlu değildir. Programcılara görev atamaz, onların kendi başlarına seçim yaparak, sorumluluk almalarını kolaylaştırır. Toplantı ve diğer buluşmaları koordine eder, takımın karşılaştığı sorunları ortadan kaldırmak için gerekli olanları yapar.

Koç

Çevik süreci tanıyan ve nasıl uygulanması gerektiğini bilen experdir. Koçun görevi proje başlangıcında çevik takımı oluşturmak yada bir araya getirmek ve onlara belirli bir süre rehberlik yapmaktır. Koç projede sorun çıktığı zaman yada takım XP yöntemlerinin dışına çıktığında müdahale eder. Zaman zaman koç implementasyonda aktif olarak rol alır. Örneğin unit testlerin nasıl doğru bir yapıda oluşturulabileceğini diğer programcılara gösterebilir.

Testçi

Müşteri tarafından oluşturulan akseptans testlerini implemente eden programcıdır. Aynı zamanda JUnit ve entegrasyon testlerinin implementasyonunda takım arkadaşlarına yardımcı olur.

Haklar ve Sorumluluklar

Proje çalışanları çoğu zaman içgüdüsel korku hissedebilirler. Bunun en büyük sebebi belirsizliktir. Ne ve nasıl yapılması gerektiği bilinmediği taktirde ekip içinde huzursuzluk doğar. Bu projenin başarısını negatif etkiler.

Projenin başarılı olabilmesi için çalışanların hissettikleri korkunun aza indirilmesi yada yok edilmesi gerekmektedir. XP bu konuda proje çalışanlarına bir takım hakların tanınması gerektiğini dikte eder. Hangi rollerin hangi haklara sahip olduğunu yakından inceliyelim.

Müşteri Hakları

Müşterinin sahip olduğu haklar şu şekilde özetlenebilir:

  • Müşteri bütçe ve zaman planlaması yapabilmek için neyin yapılabilir olduğunu ve hangi zaman biriminde yapılabileceğini bilme hakkına sahiptir.
  • Müşteri fikir değiştirerek, gereksinimler üzerinde değişiklik yapma ve yeni gereksinimlerin implementasyonunu talep etme hakkına sahiptir.
  • Müşteri programcılar tarafından sağlanabilecek en yüksek verimi ve değeri elde etme hakkına sahiptir.
  • Müşteri projede somut ilerlemeyi görme hakkına sahiptir. Bu kısa aralıklarla oluşturulan yeni sürüm ve akseptans testlerine olumlu cevap veren yeni implementasyonlarla sağlanır.
  • Müşteri  bir sonraki sürümde implemente edilecek kullanıcı hikayelerini seçme hakkıda sahiptir.

Programcı Hakları

Programcının sahip olduğu haklar şu şekilde özetlenebilir:

  • Programcı takım arkadaşlarına soru sorma ve cevap alma hakkına sahiptir.
  • Programcı kullanıcı hikayeleri için implementasyon zaman tahmini yapma hakkına sahiptir. Programcı tahminler üzerinde değişiklik yapma hakkında sahiptir.
  • Programcı, kendisine görev verilmesi yerine sorumluluk alma hakkında sahiptir.
  • Programcının herzaman yüksek kalitede iş çıkarma hakkı vardır.
  • Programcının hangi öncelik sırasına göre neyi yapması gerektiğini bilme hakkı vardır.

Süreç İşleyişi

XP projelerinde projenin gidişatını genel olarak şu şekilde özetliyebiliriz:

  • Müşteri gereksinimleri ihtiva eden kullanıcı hikayelerini oluşturur. Bunlara öncelik sırası atar. Programcılar her kullanıcı hikayesi için implementasyon zamanını tahmin ederler.
  • Müşteri  programcılarla beraber iterasyon(1-2 hafta) ve sürüm (1-2 ay) planını hazırlar. Her sürüm birden fazla iterasyon ihtiva eder ve müşteri tarafından kullanılacak özellikte çalışır bir sistemdir.
  • Müşteri ilk iterasyon (1 hafta) için gerekli kullanıcı hikayelerini tahminleride dikkate alarak seçer.
  • Programcılar iterasyon için seçilen kullanıcı hikayelerini implemente ederler. Kafalarda oluşan sorular müşteriye danışılarak cevaplandırılır.
  • İterasyon sonunda programcılar müşteriye çalışır bir sistem sunarlar. Müşteri sistemi değerlendirerek programcılara geridönüm sağlar.
  • Edinilen tecrübeler ışığında bir sonraki iterasyon planlanır. Eğer müşteri yeni gereksinimlerin implemente edilmesini isterse, bunlar için tekrar kullanıcı hikayeleri oluşturulur ve tahminler yapılır. Eğer yeni kullanıcı hikayeleri yoksa, mevcut kullanıcı hikaye listesinden en yüksek öncelik sırasına sahip olanlar seçilir ve bir sonraki iterasyondan implemente edilir.
  • İlk sürüm sonunda oluşan yazılım sistemi müşteri tarafından produktif olarak kullanıma alınır. Başka sürümler planlandıysa bir sonraki iterasyonla devam edilir.

XP Proje Safhaları

Bir XP projesi değişik safhalardan oluşur. Her sahfa, bünyesinde kendine has aktiviteler ihtiva eder. Bir sonraki resimde bir XP projesinde olması gereken safhalar yeralmaktadır.

XP projesi şu safhalardan oluşur:

  • Keşif safhası (Exploration Phase): Projenin başlangıcında keşif safhasını oluşturan aktiviteler yeralır. Bu safhada müşteri kullanıcı hikayelerini (user story) oluşturur. Programcılar teknik altyapı için gerekli deney (spike) ve araştırmayı yaparlar.
  • Planlama Safhası (Planning Phase): Keşif safhasını planlama safhası takip eder. Bu safhada müşteri programcılar yardımıyla iterasyon ve sürüm planlarını oluşturur. İterasyon planlaması için oluşturulan kullanıcı hikayelerinin implementasyon süresi programcılar tarafından tahmin edilir. Müşteri kullanıcı hikayelerine öncelik sırası vererek, iterasyonlarda hangi kullanıcı hikayelerinin öncelikli olarak implemente edilmeleri gerektiğini tespit eder. Programcılar tarafından herhangi bir kullanıcı hikayesinin implementasyon süresi tahmin edilemesse, programcılar spike solution olarak bilinen basit bir çözüm implemente ederek, kullanıcı hikayesinin gerçek implementasyonu için gerekli zamanı tahmin etmeye çalışırlar.
  • İterasyon ve Sürüm Safhası (Iterations to Release Phase): Kullanıcı hikayelerinin implementasyonu iterasyon ve sürüm safhasında gerçekleşir. Bir iterasyon bünyesinde implemente edilmesi gereken kullanıcı hikayeleri müşteri tarafından belirlenir. İmplementasyonunun işlevini kontrol etmek için müşteri tarafından akseptans testleri belirlenir. Bu testler programcılar yada testçiler tarafından implemente edilir. Her iterasyon sonunda müşteriye, çalışır bir yazılım sistemi sunulur. Bu şekilde müşterinin sistem hakkındaki görüşleri alınır (geridönüm). İterasyon son bulduktan sonra çalışma hızını tahmin etmek için bir önceki iterasyonunda elde edilen tecrübeler kullanılır ve iterasyon planı bu değerler doğrultusunda gözden geçirilir. Bir önceki iterasyonda oluşan hatalar bir sonraki iterasyonda gözden geçirilmek ve giderilmek üzere planlanır.
  • Bakım Safhası (Maintenance Phase): Bu programın bakımının ve geliştirilmesinin yapıldığı safhadır. Bu safhada kullanıcılar için egitim seminerleri hazırlanır ve küçük çapta eklemeler ve sistem hatalarının giderilmesi için  işlemler yapılır. Müşterinin istekleri doğrultusunda bir sonraki büyük sürüm için çalışmalara başlanır. Bu durumda tekrar keşif safhasına geri dönülmesi ve oradan işe başlanması gerekmektedir.

Bu yazıyı PDF olarak edinebilirsiniz.

  Extreme Programming Nedir? (210,6 KiB, 8.647 yükleme)

Tasarım Şablonu Nedir?

Yazılım esnasında tekrar eden sorunları çözmek için kullanılan ve tekrar kullanilabilir tipte kod yazılımını destekleyen bir ya da birden fazla sınıftan oluşmuş modül ve program parçalarına Tasarım Şablonu denir. Tasarım şablonları, programcılar tarafından edindikleri tecrübeler doğrultusunda oluşmuş kalıplardır. Bu kalıplar sorunu tanımlıyarak, çözümü için gerekli atılması gereken adımlari ihtiva ederler. Kullanıcı kalıbı, tanımlanmış sorunu çözmek için tekrar tekeri icat etmek zorunda kalmadan kullanabilir.

Tasarım şablonları aşağıda yeralan ortak özelliklere sahiptir:

  • Edinilen tecrübeler sonunda ortaya çıkmışlardır.
  • Tekerin tekrar icat edilmesini önlerler.
  • Tekrar kullanılabilir kalıplardır.
  • Ortak kullanılarak daha büyük problemlerin çözülmesine katkı sağlarlar.
  • Devamlı geliştirilerek, genel bir çözüm olmaları için çaba sarfedilir.

Program bakımı ve geliştirilmesi için ilk yazılım sürecinden daha çok enerji sarfedilir. Bu yüzden yazılım esnasında esnek bir yapının ve mimarinin oluşturulmasına dikkat edilmesi gerekmektedir. Esnek mimariler için değişik türde tasarım şablonları kullanılabilir. En basit ve uygulaması kolay bir tasarım şablonunun kullanılması, hiçbir tasarım şablonunun kullanılmamasından daha iyidir. İyi bir yazılım mühendisi olabilmek için tasarım şablonları ve kullanım alanları hakkında ihtisas yapmış olmak gerekmektedir.

 

Tasarım Şablonu Neden Kullanılır?

Her tasarım şablonunun belirli bir ismi vardır ve bu isim kullanıldığı zaman hangi tasarım şablonundan bahsedildiği hemen anlaşılır. Bu sebepten dolayı yazılım ekibinin kullanacağı ortak bir kelime hazinesi oluşur. Programcılar takım içinde tasarım şablonlarının isimlerini kullanarak, hangi sorunlar üzerinde çalıştıklarını kolaylıkla anlatabilirler. Bu durum ayrıca takım içinde tasarım şablonlarını tanımayan programcılar için duydukları tasarım şablonlarını öğrenmeye yönlendirecek bir motivasyon kaynağı oluşturur. Tasarım şablonlarının kullanılması konseptüel olarak bir üst seviyede çalışılmasını ve düşünülmesini sağlar. Nesneler seviyesinde sorunları çözmek her zaman kolay olmayabilir, lakin tasarım kalıpları seviyesinde düşünüldüğü zaman, problem çözüm işlemi kolaylaşır.

 

Tasarım Şablonu Kategorileri

Tasarım şablonları değişik kategorilere ayrılır. Bunlar:

  • Oluşturucu tasarım şablonları (creational patterns)
  • Yapısal tasarım şablonları (structual patterns)
  • Davranışsal tasarım şablonlar (behavioral patterns)

 

Oluşturucu

Yapısal

Davranışsal

– Abstract Factory (soyut fabrika)

– Builder (inşaatçi)

– Factory Method (fabrika)

– Prototype  (prototip)

– Singleton (yanlızlık)

– Adapter

– Bridge (köprü)

– Facade (cephe)

– Decorator (dekotatör)

– Composite (kompozit)

– Flyweight (sinek siklet)

– Proxy (vekil)

 

– Command (komut)

– Memento (hatıra)

– Strategy (strateji)

– Iterator (tekrarlayıcı)

– State (durum)

– Chain Of Responsibility (sorumluluk zinciri)

– Mediator (aracı)

– Observer (gözlemci)

– Template Method (şablon metot)

– Visitor (ziyaretçi)

 

Bu tasarım şablonları yanısıra J2EE Patterns olarak bilinen tasarım şablonlarını inceliyecegiz.

J2EE

– MVC

– Data Access Object

– Front Controller

– Business Delegate

– Intercepting Filter

– Service Locator

 

Abstract Factory (Soyut Fabrika)
Aynı sınıf ailesine ait nesnelerin oluşturulmasında kullanılır. Kullanılan altsınıfları gizliyerek, tranparen olarak kullanılmalarını mümkün kılar.

Builder (İnşaatçi)
Kompleks yapıdakı bir nesneyi değişik parçaları bir araya getirerek oluşturmada kullanılır. Birden fazla adım içeren nesne üretim sürecinde, değişik parçalar birleştirilir ve istenilen tipte nesne oluşturulur.

Factory Method (Fabrika)
Yeni nesneler oluşturmak için kullanılır. Nesnenin hangi somut sınıftan olacağına alt sınıf implementasyonu belirler.

Prototype (Prototip)
Sistem içinde kullanılan bazı nesnelerin oluşturulmaları, büyük ve değişik kaynakların kullandıklarından dolayı zaman alıcı olabilir. Bu gibi nesneleri new operatörü ile yeniden oluşturmak yerine, Prototype tasarım şablonu kullanılarak mevcut bir nesneden klonlanabilir. Bu şekilde oluşan nesne bir prototiptir ve set metodları kullanılarak istenilen özelliklere göre yapılandırılabilir.

Singleton (Yanlızlık)
Bazı şartlar altında bir sınıftan sadece bir nesnenin oluşturulması ve oluşturulan bu nesnenin tüm sistemde kullanılmasi gerekebilir. Singleton tasarım şablonu kullanılarak, bir sınıftan sadece bir nesnenin oluşturulması sağlanabilir.

Adapter
Adapter tasarım şablonu yardımı ile, sistemde mevcut bulunan bir sınıfın sunduğu interface (sınıf metotları) başka bir sınıf tarafından kullanılabilir şekilde değiştirilir (adapte edilir). Bu adapter yardımı ile birbiriyle beraber çalışamıyacak durumda olan sınıflar, birlikte çalışabilir hale getirilir.

Bridge (Köprü)
Bridge tasarım şablonu, modelleme esnasında oluşan soyut oluşumlar ve bunların implementasyonunu ayırmak için kullanılır. Bu yöntem sayesinde sınıf hiyerarşileri daha esnek bir hale getirilebilir, çünkü üst sınıflar bünyelerinde barındırdıkaları soyut metodları bir interface sınıfına taşıyarak, alt sınıfların istedikleri bir implementasyonu kullanmalarına izin verirler.

Facade (Cephe)
Bir komponentin sunmuş olduğu hizmetten yararlanabilmek için, komponentin dış dünya için tanımlamış olduğu giriş/çıkış noktaları (input/output interface) kullanılır. Komponent sadece bu giriş/çıkış noktaları üzerinden dış dünya ile iletişim kurar ve iç dünyasını tamamen gizler. Bu komunikasyon noktaları genelde Facade tasarım şablonu kullanılarak programlanır.

Decorator (Dekoratör)
Mevcut bir sınıf hiyerarşisini ya da sınıfın yapısını değiştirmeden, oluşturulan nesnelere yeni özelliklerin eklenmesi işlemini gerçekleştirmek için decorator tasarım şablonu kullanılır.

Composite (Kompozit)
Composite tasarım şablonu, bir sistemin bütünü ve parçaları arasındaki ilişkileri modellemek için kullanılır. Sistemin bütününü oluşturan parçalar, kendi içlerinde alt parçalardan oluşabilir. Composite tasarım şablonu, kullanıcı sınıfın, sistem, sistemin parçaları ve alt parçalar arasında ayrım yapmadan nesneleri kullanmasına izin verir. Bu şekilde sistem yazılımı ve kullanımı daha sadeleştirilmis olur.

Flyweight (Sinek Siklet)
Flyweight tasarım şablonunu kullanılarak, kullanılan nesne adedi aşağıya çekilebilir.

Proxy (Vekil)
Bir nesnenin kullanımını kontrol etmek için Proxy tasarım şablonu ile, korunması gereken nesneye vekilen bir nesne oluşturulur.

Command (Komut)
Bir nesne üzerinde bir işleminin nasıl yapıldığını bilmediğimiz ya da kullanılmak istenen nesneyi tanımadığımız durumlarda, command tasarım şablonu ile yapılmak istenen işlemi bir nesneye dönüştürerek, alıcı nesne tarafından işlemin yerine getirilmesi sağliyabiliriz.

Memento (Hatıra)
Bir nesneyi, daha önce sahip olduğu bir duruma tekrar dönüştürebilmek için Memento tasarım şablonu kullanılır.

Strategy (Strateji)
Bir işlemi yerine getirmek için birden fazla yöntem (algoritma) mevcut olabilir. Yerine göre bir yöntem seçip, uygulamak için Strategy tasarım şablonu kullanılır. Her yöntem (algoritma) bir sınıf içinde implemente edilir.

Iterator (Tekrarlayıcı)
Iterator tasarım şablonu ile bir listede yeralan nesnelere sırayla, listenin yapısını ve çalışma tarzını bilmek zorunluluğu olmadan erişilir ve bu nesneler üzerinde işlem yapalır.

State (Durum)
State tasarım şablonu kullanarak, bir nesnenin davranışı, sahip olduğu değerler değiştiği zaman değiştirilebilir. Bu durumda sanki nesne sahip olduğu sınıfı değiştirmiş gibi olacaktır.

Chain Of Responsibility (Sorumluluk Zinciri)
Chain of responsibility sorumluluk zinciri anlamına gelmektedir. Sisteme gönderilen bir istediğin (komut) hangi nesne tarafından cevaplanması gerektiğini bilmediğimiz durumlarda ya da isteği yapan nesne ve servis sağlayan nesne arasında sıkı bir bağ oluşmasını engellememiz gerektiğinde Chain of Responsibility tasarım şablonu kullanılır. Bu tasarım şablonunda servis sağlayan ilgili tüm nesneler bir kolye üzerindeki boncuklar gibi birbirleriyle ilişkili hale getirilir. Bir nesne zincirdeki kendinden sonraki nesneyi tanır ve isteği kendi cevaplayamadığı durumda, kendinden sonraki nesneye iletir. Bu işlem, zincirde bulunan doğru servis saglayıcı nesneyi bulana kadar devam eder.

Mediator (Aracı)
Mediator tasarım şablonunu nesnelerin yönetimi ve aralarındaki komunikasyonun merkezi bir noktadan koordinasyonu için kullanılır. Bu nesneler arasındaki bağı azaltır ve sadece bir sınıfı komunikasyonu koordine etmekle sorumlu kılar.

Observer (Gözlemci)
Sistem bünyesinde, bir nesnede meydana gelen değişikliklerden haberdar olmak isteyen diğer nesneler olabilir. Bu durumda haberdar olmak isteyen nesneler abone olarak, abone oldukları nesnede meydana gelen değişikliklerden haberdar edilirler. Abone olan nesne aboneliğini iptal ederek, abone olduğu nesne ile arasındakı ilişkiyi sonlandırabilir.

Template Method (Şablon Metot)
Template method ile bir algoritma için gerekli işlemler soyut olarak tanımlanır. Alt sınıflar algoritma için gerekli bir yada birden fazla işlemi kendi bünyelerinde implemente ederek, kullanılan algoritmanın kendi istekleri doğrultusunda çalışmasını sağlıyabilirler.

Visitor (Ziyaretçi)
Visitor tasarım şablonu, bir sınıf hiyerarşisinde yeralan sınıflar üzerinde değişiklik yapmadan, bu sınıflara yeni metodların eklenmesini kolaylaştırır. İstenilen metod bir visitor sınıfında implemente edilir.

MVC
MVC (Model – View – Controller) kullanılarak değişik görevleri olan katmanlar oluşturmak mümkündür. MVC tasarım şablonu özellikle web frameworklerinde (Struts, Spring MVC..) sıkça kullanılan bir tasarım şablonudur.

DAO
Data access objects (DAO) tasarım şablonu ile, kullanılan veritabanına erişim ve veri depolama-edinme işlemi daha soyutlaştırılarak, diğer katmanların veritabanına olan bağımlılıkları azaltılır. DAO ile diğer katmanlar etkilenmeden veritabanı ve bilgibankası değiştirilebilir.

Front Controller
Front Controller tasarım şablonu ile sisteme yöneltilen tüm istekler (request) merkezi bir yerde toplanarak işlem görürler.

Business Delegate
Business Delegate tasarım şablonu ile, kompleks yapıda olabilecek işletme (business) katmanı ile gösterim (presentation) katmanı arasına, gösterim katmanı isteklerini işletme katmanına delege edecek BusinessDelegate isminde bir sınıf yerleştirilir. Bu sınıfın öncelikli görevi, işletme katmanında yeralan EJB komponentlerini lokalizasyonu için gerekli lookup işlemlerini gösterim katmanı için transparan hale getirmektir.

Intercepting Filter
Intercepting Filter tasarım şablonu ile, kullanıcının isteği işleme alınmadan önce filtreler kullanılarak süzgecten geçirilir.

Service Locator
Service Locator, işletme katmanında bulunan komponentlerin lokalizasyonu için kullanılır.

Tasarım şablonları hakkında detaylı bilgiyi Java Tasarım Şablonları ve Yazılım Mimarisi isimli kitabımda bulabilirsiniz.