Dr. Volkan Tunalı'nın Kişisel Blogu

Bilgisayar, Teknoloji, Bilim, Sanat

Archive for Kasım, 2009

Yazılımın Bakımı (Software Maintenance) Nedir?

leave a comment

Zaman içerisinde değişim ihtiyacı duyulmayacak bir yazılım sistemi düşünülemez. Kullanıcı ya da müşterilerin ihtiyaçlarındaki değişimlerin sisteme yansıtılması gerekir. Ayrıca, yeni bir donanım ya da yazılım altyapısı nedeniyle sistemin çalışma koşulları değişebilir. Tabii ki testler sırasında farkedilmeyen hatalar tespit edilebilir ve giderilmesi gerekir.

Yazılımın dağıtılması ve kullanıma başlanmasından sonra yazılımda yapılacak değişiklikler yazılımın bakımı (software maintenance) olarak adlandırılır. Bu değişiklikler basit kodlama hatalarının düzeltilmesi (bug-fixes) şeklinde olabileceği gibi tasarımdan kaynaklanan hataların giderilmesi gibi daha kapsamlı değişiklikler şeklinde de olabilir. Yazılımın bakımı aslında yazılımın evrimleşmesidir. Yazılımın yaşamına devam edebilmesi için gerekli değişikliklerin uygulanmasıdır.

Genel hatlarıyla 3 bakım türü vardır:

1. Düzeltici bakım: Tespit edilen hataların giderilmesi işlemidir. Kodlama hatalarını düzeltmek genelde az maliyetlidir. Tasarımdan kaynaklı hataların giderilmesi ise bazı sistem bileşenlerinin baştan yazılmasını vb. gerektirebilir ve nispeten yüksek maliyetlidir.

2. Uyarlayıcı (Adaptif) bakım: Yazılımın yeni bir çalışma ortamına uyarlanmasıdır. Bu bir donanım platformu değişikliği olabileceği gibi (32 bitten 64bite geçiş gibi) farklı bir işletim sistemine uyarlama şeklinde de olabilir (kodun Windows’dan Linux’a taşınması gibi). Ayrıca, veritabanı sistemi değişikliği de bu türden bir bakım olarak görülebilir (MS SQL Server bağımlı kodların Oracle’a uyarlanması gibi).

3. İyileştirici bakım: Sisteme yeni işlev ve özelliklerin eklenmesi, performansın arttırılması gibi bakım çalışmalarıdır.

80li ve 90lı yıllarda yapılan araştırmalar göstermiştir ki bakım çalışmalarının %65′i iyileştirici, %18′i uyarlayıcı ve %17′si düzeltici bakım şeklinde gerçekleşmektedir. Bu rakamları günümüzde de doğru kabul edebiliriz.

Genellikle bir sisteme sistem çalışmaya başladıktan sonra yeni bir işlev eklemek, aynı işlevin henüz geliştirme sürecindeyken eklenmesine göre çok daha maliyetlidir.

Written by vtunali

Kasım 30th, 2009 at 4:12 am

Database Smells

leave a comment

Programlamada “code smells” olarak bilinen bir kavram vardır: artık refactor (yeniden düzenleme) edilme zamanı gelmiş olan kod kendini belli etmeye başlar. Örneğin çok uzun metodlar, kopyala-yapıştır ile çoklanmış kod blokları kötü kokmaya başlar, temizliğe gerek vardır.

Scott Ambler ve Pramod Sadalage, “Refactoring Databases: Evolutionary Database Design” isimli kitaplarında veritabanı tasarımına “Database Smells” diye bir kavram getirdiler. Aşağıda, bir veritabanının yeniden düzenlemeye ihtiyacı olduğunun bazı göstergelerini kısa maddeler halinde bulacaksınız.

  • Çok amaçlı kolon: Eğer bir kolon birden çok amaçla kullanılıyorsa, muhtemelen o kolonu anlamlandırmak için kod tarafında ekstra çaba sarfediliyordur ve muhtemelen bu iş diğer bazı kolonlardaki değerlere bağlı olarak yapılıyordur.
  • Çok amaçlı tablo: Benzer şekilde, çeşitli türdeki varlıkları aynı tabloda saklamaya çalışmak da tasarımda bir kusur olduğunun göstergesidir.
  • Çoklanmış veri: Aynı verinin veritabanın bir çok yerinde bulunması zaman içerisinde tutarsızlıklar oluşmasına yol açabilir.
  • Çok fazla kolonu olan tablo: Bir tabloda çok fazla kolon olması genellikle o tabloda çeşitli türlerde varlıklara ait veri tutulmaya çalışılmasından ileri gelir.
  • Çok fazla satırı olan tablo: Büyük tablolar performans sorunlarını da beraberinde getirir. Mümkün ise bazı kolonların ya da bazı satırların başkta tablolara dağıtıldığı bir tasarıma gidilmesi ciddi performans kazancı sağlayacaktır.
  • Akıllı kolon: Akıllı kolon, kolon verisinin değişik bölümlerinin değiişik anlamlara geldiği kolonlardır. Örneğin, müşteri numarasının ilk 4 hanesi müşteri grubunu, sonraki 2 hanesi kayıt yılını vs. gösteriyor olabilir. Bazen de bir kolonda komple XML olarak veri tutuluyor olabilir. Ancak bu tür kolonlarda ayrıntılara inmek ekstra işlemlerin yapılmasını gerektirir. En iyisi bu tür kolonları yeniden organize etmektir.
  • Değiştirmekten korkmak: Eğer veritabanı şemasında bir değişiklik yaparak birşeyleri bozmaktan korkuluyorsa, o veritabanının yeniden düzenlenme zamanı gelmiştir. Eğer bu yapılmazsa, ileriye dönük olarak işler sadece daha da kötüleşecektir.

Ambler ve Sadalage, kitaplarında bu kötü kokular için yeniden düzenleme tekniklerini hem veritabanı şeması olarak hem de SQL ve çeşitli dillerde kod örnekleriyle anlatıyorlar.

Kaynak: “Refactoring Databases: Evolutionary Database Design“, Scott Ambler & Pramod Sadalage.

Written by vtunali

Kasım 21st, 2009 at 9:40 pm

Uç Programlama (Extreme Programming XP) Nedir?

leave a comment

Uç Programlama (XP), yazılım geliştirme süreci boyunca son derece kaliteli olmak koşuluylaçalıştırılabilir kod üretmeye odaklanmış bir yazılım geliştirme metodolojisidir. Yazılım geliştirme sürecinin en temel, en önemli ve final çıktısı ya da ürünü çalıştırılabilir kod olduğundan, XP metodolojisi sürecin en başından itibaren çalıştırılabilir kodu sürecin merkezinde tutmaktadır. İşte bu yüzden bu metodolojinin adı XP’dir.

Uç Programlama kısa adımlardan oluşan tekrarlı bir süreçtir. Her bir tekrar süresi birkaç gün ila birkaç haftadan daha uzun değildir. İlk adımın sonucunda geliştirilmekte olan sistemin minimum seviyede çalıştırılabilir bir örneği üretilmiş olmalıdır. Bu ilk adımdan sonraki her bir tekrar adımında bir önceki adıma göre daha fazla özelliğe sahip ve aynı zamanda iyileştirilmiş bir sürüm ortaya çıkarılması hedeflenmektedir. Bu şekilde sık tekrarlar ile sistemin bütünü
tamamanmış olacaktır.

Uç Programlama, her bir adımda genişletilebilirlik ve sürdürülebilirlik özellikleri bakımından yüksek kalitede kod üretimine önem vermektedir. Her bir adımın temel hedefi geliştirmek ve refactor etmektir. Geliştirmek, yeni işlevler ve özellikler eklemek demektir. Refactor etmek ise çalışan kodun işleyişine zarar vermeden kodun kalitesinin arttırılması amacıyla yeniden yapılandırılması demektir. Refactor etmek, Uç Programlamanın ısrarla üzerinde durduğu bir işlemdir.

Uç Programlama’nın özünde aşağıdaki uygulamalar yer alır:

  • Planlama: Her tekrar adımına basit bir planla başlanır ve gerekli oldukça bu planda değişikliğe ve iyileştirmeye gidilir.
  • Sık ve küçük sürümler: Her tekrar adımında çalışan bir sürüm temel hedeftir. Tekrarlamaların süresi de birkaç haftadan daha uzun olmamalıdır.
  • Basit tasarım: Tasarım mümkün olduğunca basit tutulmalı, gerektiğinde refactor edilmelidir.
  • Önce test: Kod yazılmadan önce yazılacak kodun testinin yazılmasıdır.
  • Refactor etme: Kod tekrarlarından uzak durmak, sade ve temiz kod elde etmek için sürekli olarak refactor edilmelidir.
  • Çift programcı: Kodun hep çiftler halinde yani eşli olarak yazılmasıdır.
  • Sürekli bütünleştirme (Continuos Integration): Her kodlama görevi tamamlanır tamamlanmaz ana sistemle bütünleştirilmelidir.
  • Haftada 40 saat çalışma: Geliştirme ekiplerinin verimli çalışabilmesi için aşırı çalışma saatlerinden kaçınılmalıdır.
  • Müşteri ile yakın iletişim: Müşterinin tam zamanlı olarak geliştirme ekibiyle yakın temas halinde bulunması ve sürece her an dahil olabilmesi gerekir.
  • Kodlama standartları: İsimlendirme, kaynak kod düzenleme ve dokümantasyon için yaygın standartların tüm ekip tarafından benimsenmesi gereklidir.

Written by vtunali

Kasım 18th, 2009 at 12:31 am

Primary Key: Identity mi GUID mi?

leave a comment

Birincil Anahtar (Primary Key) olarak ne kullanılması gerektiği veritabanı tasarımında en sık karşılaşılan ve çözümü de çok kolay olmayan bir sorundur. Aslında veritabanı teorisi açısından en doğrusu Doğal Anahtar (Natural Key) olan kolonun birincil anahtar olarak kullanılması. Ancak pratikte bunun çeşitli sakıncaları bulunduğu için pek tercih edilmiyor. Günümüzün Nesne Yönelimli (Object Oriented) tasarımlarıyla daha iyi örtüştüğü için Doğal anahtar yerine Surrogate Key (harici, vekil anahtar) kullanımı daha çok tercih ediliyor. Özellikle de ORM (Object Relational Mapping) gibi veri ve iş mantığı katmanlarının kullanıldığı yazılım projeleri için Surrogate Key tek seçenek durumunda.

Surrogate Key’i kısaca tanımlamak gerekirse; kayıtlardaki veriyle hiçbir doğal bağlantısı ve ilgisi olmayan, tek amacı kayıtları eşsiz olarak nitelemek olan, genellikle de değerini veritabanı sisteminin kendisinin ürettiği tablo kolonudur. Çoğunlukla bu kolonun veri tipi olarak otomatik artan (Auto Increment, Identity, Sequence gibi) Integer ya da GUID (Globally Unique Identifier = Küresel Eşsiz Tanımlayıcı) tercih edilmektedir. İşte asıl sorun da bu noktada yaşanmakta: Bu ikisinden hangisini seçmeli ve neden? Ne yazık ki bu sorunun tek ve kesin bir yanıtı yok. Tasarlanmakta olan sistemin bugünkü ve de öngörülebilen gelecek ihtiyaçlarına bağlı olarak bir tercih yapılması gerekiyor. Bu tercihi yaparken her iki seçimin de avantaj ve dezavantajlarını ortaya koymak ve bunları iyi değerlendirmek gerekiyor. Bu makalede her iki veri tipini ayrı ayrı ele alacağız ve bir sonuca ulaşmaya çalışacağız.

GUID – Globally Unique Identifier

+ Bu veri tipinin en büyük avantajı evrensel olarak (ve en azından teoride) eşsiz değerlere sahip olması. Sadece bir tablodaki bütün satırlar değil, veritabanındaki tüm satırlar, hatta ve hatta evrendeki tüm tablolardaki tüm satırlar eşsiz kimliğe sahip olacak.

+ Eşsiz olma özelliğinden dolayı dağıtık durumdaki veritabanlarını bir gün gelip de merkezi hale getirmek gerektiğinde yani merge etmek (birleştirmek) gerektiğinde hiçbir sorun yaşanmadan, hiçbir dönüşüme gerek kalmadan bu işlem gerçekleştirilebilir. Dolayısıyla bu veri tipinin tercih edilmesinde kurulan sistemin böyle bir gereksinime cevap verebilir olmasının gerekliliği en önemli etkendir. (Örneğin MSSQL Server’da replikasyon yapıldığında eğer yok ise sistem her tabloya bir adet GUID kolon ekliyor.)

+ Programsal olarak üretilebildiği için veritabanına Insert işlemi sırasında değeri bilinebilir ve böylece Insert’ten sonra bir kez de en son kullanılmış değeri elde etmek için veritabanı sunucusuna bir erişime daha ihtiyaç duyulmaz. ORM açısından da bunun güzel bir özellik
olduğu düşünülebilir.

- GUID’nin en büyük dezavantajı veri boyutunun çok büyük olmasıdır. GUID’nin boyutu 128 bit = 16 byte’tır. Birincil anahtar olarak GUID kullanılan bir tablodaki diğer bütün index’lerin de bu 16 byte’ı taşıyacağı anlamına gelir. Sonuç olarak fazladan veritabanı boyutu ve disk alanı demektir. Elbette ki fazladan I/O işlemi = performans sıkıntısı.

- Veritabanı açısından değil belki ama yazılım geliştiriciler açısından B85E62C3-DC56-40C0-852A-49F759AC68FB gibi değerlerin debug etme işini epeyce zorlaştıracağı da bir gerçek.

- Çoğu veritabanı yönetim sistemi artık GUID veri tipini kendiliğinden destekliyor olsa da bunu doğal olarak desteklemeyen sistemlerde karakter veri tipi olarak tutulması gerekebilir (gerçek bir uygulamada böyle yapılmak zorunda kalındığını biliyorum).

- GUID’ler üretildiklerinde belli bir sıra takip etmezler, yani tamamen rastgele üretilirler. Yani, sonradan üretilen GUID, bir önceki GUID’den daha büyük olmak zorunda değildir. Bu durum bize Clustered Index şeklindeki birincil anahtar olarak tanımlanan GUID kolonlarda büyük bir
dezavantaj oluşturmaktadır. Bildiğiniz gibi Clustered Index demek, verilerin bu index’e göre veritabanı sayfaları üzerinde gerçekten doğal sırasıyla tutulması anlamına geliyor. Yani Clustered olmayan indexler gibi sadece index olmaktan ibaret değil. Bu durumda her sırasız Insert için tabloya ait sayfalarda yer değiştirme ve yer ayırma yapılması gerekiyor. Bu soruna çözüm olarak mesela MSSQL Server 2005′ten itibaren Sequential GUID gibi -bence zorlama ve uydurma- veri tipleri gelmekte ya da sıralı GUID üreten fonksiyonlar yazılmakta. Ek olarak, GUID türündeki birincil anahtarların Clustered yapılmaması da dikkat edilmesi gereken bir konu.

Identity Integer

+ Eğer 4 byte’lık Integer veri tipi kullanılırsa işlemci için en doğal ve en hızlı işlenen veri tipi olması bakımından ilişkisel veritabanı operasyonları için en uygun veri tipi olduğu söylenebilir.
16 byte genişliğinde GUID veri tipiyle kıyaslandığında veritabanı ve disk alanı bakımından da son derece avantajlı olduğu görülüyor.

+ Sıralı üretildikleri için GUID’deki Clustered Index problemi yaşanmıyor.

+ Program geliştiriciler için debug edilmesi, gözle takip edilmesi son derece kolaydır.

- Kayıt Insert edildikten sonra son üretilen Identity değeri elde etmek için sunucuya fazladan bir erişim yapmak ve işlem yaptırmak gerekiyor.

- Ayrık veritabanlarını merkezi olarak birleştirmek gerektiğinde çakışan değerler için ekstra uğraş gerekiyor.

Sonuç ve Değerlendirme

Dağıtık veritabanlarının replike edilmesi ya da merkezileştirilmesi gibi ihtiyaçlar söz konusu ise GUID büyük boyutuna ve diğer dezavantajlarına rağmen en iyi seçenek gibi görünüyor. Bunun dışında, 32 bit ya da gerçekten gerekli ise 64 bit Integer Identity şeklindeki Surrogate Key daha az masraflı, daha fazla sistem tarafından doğal olarak desteklenen ve daha pratik bir seçenek durumunda. Bu aşamada kişisel bir tercih belirtmem gerekirse mutlaka gerekmiyorsa GUID’den uzak durmayı seçiyorum.

Written by vtunali

Kasım 18th, 2009 at 12:13 am

Veri Madenciliği (Data Mining) Kitapları

leave a comment

Veri Madenciliği (Data Mining) ve Metin Madenciliği (Text Mining) alanlarında doktora araştırma ve tez çalışmalarımda kullandığım ve içeriğini çok yararlı bulduğum bazı kitapları burada tanıtmak istiyorum. Bunların bir çoğunu e-book olarak bulmak mümkün (tabii ki ben bunlara bağlantı vermeyeceğim). Şimdilik 3 tanesini yazdım, devamı gelecek.

Data Mining: Concepts and Techniques, Second Edition


Kitap Adı: Data Mining: Concepts and Techniques, Second Edition
Yazarları: Jiawei HanMicheline Kamber
Yayınevi: Morgan Kaufmann Publishers

Veri Madenciliği alanında en çok bilinen kitap bu olsa gerek. Bu alana bir başlangıç yapmak isteyenlere tavsiye ederim.









Introduction to Data Mining


Kitap Adı: Introduction to Data Mining
Yazarları: Pang-Ning TanMichael SteinbachVipin Kumar
Yayınevi: Addisson-Wesley

Kitapla ilgili ayrıntılı bilgi ve örnek bölümlere .pdf formatında erişim için http://www-users.cs.umn.edu/~kumar/dmbook/index.php adresini ziyaret edebilirsiniz. Bu adreste ayrıca kitapla ilgili çeşitli sunular da yer almaktadır.







Grouping Multidimensional Data: Recent Advances in Clustering


Kitap Adı: Grouping Multidimensional Data: Recent Advances in Clustering
Yazarları: Jacob KoganCharles NicholasMarc Teboulle (Editörler)
Yayınevi: Springer

Kümeleme alanında çeşitli güncel makalelerin derlenmesiyle oluşturulmuş bir kitap.










Written by vtunali

Kasım 12th, 2009 at 12:43 am