Modelleme dillerinin Yazılım Mühendisliği alanında kullanımının artmasıyla sadece yazılım kaynak kodunun değil bir yazılım modelinin de kalitesini ölçmek ve kontrol etmek önemli hale gelmiştir. Ancak bir yazılım ürününün kalitesini ölçebilmek için öncelikle o yazılım ürününden kalite anlamında ne beklendiği ortaya konulmalıdır. Bu çalışma, Birleşik Modelleme Dili (UML) kullanılarak geliştirilen nesne tabanlı yazılımların model seviyesinde gözlenebilen bazı yapısal özelliklerinin yazılım kalitesi üzerine etkilerini incelemektedir. Yazılım kalitesi yazılımın hata yatkınlığı olarak tanımlanmıştır. Çalışma kapsamında Aselsan bünyesinde geliştirilen gömülü ve gerçek zamanlı yazılım bileşenleri analiz edilmiştir. Yazılım bileşenlerinin yapısal özelliklerini yansıtan ve UML modelleri üzerinden ölçülen yazılım tasarım metrikleri ve bu bileşenlere ait hata yatkınlık metrikleri arasındaki ilişki ortaya konulmuştur. Yazılım tasarım metrikleri ve hata yatkınlık metrikleri arasındaki ilişki istatistiksel olarak doğrulanmıştır.
Bir yazılımın kalitesini ölçebilmek için o yazılımdan kalite anlamında ne beklendiği ortaya konulmalıdır. Hata yatkınlığı bir yazılımın kalitesine yönelik önemli bir göstergedir. Literatürde yazılımın hata dayanıklılığını ölçmek üzere, hata sayısı ve hata yoğunluğu gibi, farklı metrikler kullanılmıştır. Ayrıca [1] gibi yazılıma ait bir takım tasarım metrikleri ile yazılımın hataya yatkınlığını deneysel olarak ilişkilendirmeye çalışan çalışmalar mevcuttur. Chidamber ve Kemerer [2] tarafından ortaya konulan nesne tabanlı yazılımlara ait tasarım metrikleri hatalı yazılım bileşenlerini tespit etmek için sıklıkla kullanılmıştır. Modelleme dillerinin yazılım mühendisliği alanında kullanımının artmasıyla bir yazılım modelinin kalitesini ölçmek ve kontrol etmek daha önemli hale gelmiştir. Nesne tabanlı yazılımların geliştirilmesi amacıyla en sık kullanılan modelleme aracı Birleşik Modelleme Dili (UML)'dir. UML tasarım metriklerinin yazılımın hataya yatkınlığını ölçmek ve kontrol etmek amacıyla kullanılmasına dair oldukça az çalışma bulunmaktadır [3].
Bu çalışma kapsamında, UML kullanılarak geliştirilen nesne tabanlı yazılımlara ait tasarım metrikleri ile yazılımın hataya yatkınlığı arasındaki ilişki incelenmiştir. Araştırma konusu olan yazılım bileşenleri Aselsan Savunma Sistem Teknolojileri Sektör Başkanlığı Gömülü ve Gerçek Zamanlı Yazılım Tasarım Müdürlüğü bünyesinde geliştirilen atış kontrol yazılımlarına aittir. Bütün metrikler incelenen yazılım bileşenlerinin UML modelleri üzerinden ölçülmüştür. Hata yatkınlığı metrikleri Aselsan'da kullanılan hata izleme aracından elde edilmiştir.
Bildirinin geri kalanı şu şekilde düzenlenmiştir: Bölüm 2'de yazılım kalitesi ve kaliteyi etkileyen faktörler ile ilgili literatür bilgileri özetlenmiştir. Bölüm 3'te yapılan çalışmanın yöntemi hakkında bilgi verilmiştir. Bölüm 4'te çalışma kapsamında elde edilen bulgular ortaya konulmuştur. Bölüm 5'te ise değerlendirme ve sonuçlara yer verilmiştir.
Farklı özelliklerdeki yazılım ürünleri için farklı kalite hedefleri öne çıkmaktadır. Örneğin, bir istatiksel analiz sistemi için en önemli fonksiyonel olmayan gereksinim güvenilirlik iken bir banka sistemi için güvenlik daha ön plandadır [4]. Bu sebeple, bir yazılım ürünü için doğru kalite hedefleri koyabilmek adına kalite gereksinimi çalışması yapılmalıdır. Yüksek kalitede yazılım ürünleri üretebilmek için kalite gereksinimlerini karşılayan doğru kalite modelleri kullanmak çok önemlidir. Kullanılacak kalite modelini seçmede iki yöntem izlenebilir. Bunlardan biri ISO/IEC 9126 gibi genel kalite modelini kullanmaktır. Ancak, bu tür kalite modelleri soyut kalmakta ve uyarlamada sıkıntılar yaşanmaktadır. Diğer bir yöntem ise mevcut kalite modellerinden yararlanarak kendi kalite modelini belirlemektir. İkinci yöntem özelleşmiş kalite gereksinimlerini karşılayan doğru kalite modelini bulabilmek için daha uygundur [5,6].
Gömülü ve gerçek zamanlı yazılımlar yüksek güvenlik, güvenilirlik ve performans gereksinimleri ile birlikte geniş bir uygulama alanına sahiptir. Bu yüzden yazılım kalitesi gömülü ve gerçek zamanlı yazılım içeren sistemlerde oldukça önemlidir [7]. Gerçek zamanlı bir yazılım ürünü için hata dayanıklılığı bir kalite göstergesi olarak kullanılabilir.
Literatürde yazılım kaynak kodundan kalite ölçümü yapabilmek için önerilen birçok metrik bulunmaktadır. Chidamber ve Kemerer [2] nesne tabanlı yazılımların kalitesini değerlendirmek için metrikler önermişlerdir. Bu değerli çalışmada yazılım tasarım kalitesinin altı adet kalite metriği kullanılarak ölçülebileceği belirtilmiştir. Bir diğer önemli metrik seti ise MOOD metrikleri [8] olarak bilinmektedir. Bu metrikler kalıtım (inheritance), bilgi saklama (information hiding), çok biçimlilik (polymorphism) gibi nesne tabanlı tasarım yöntemlerini ölçmek için kullanılır. Bir başka çalışmada [9] Lorenz ve Kidd nesne tabanlı bir yazılımın durağan niteliklerini ölçebilmek için yazılım metrikleri ortaya koymuşlardır. Model tabanlı yazılım geliştirmenin yaygınlaşması ile birlikte sadece yazılım kaynak kodunun değil aynı zamanda modellerin de kalitesinin ölçülmesi önemli hale gelmiştir. Bugün birçok kuruluş UML modellerini tasarım veya kaynak kod üretme gibi amaçlarla kullanmaktadır. Nugroho ve arkadaşları [3] UML metriklerinin hata yatkınlığı yüksek sınıfı bulmada önemli olduğunu deneysel olarak göstermişlerdir.
Aşağıdaki konu başlıklarında mevcut çalışma kapsamında kullanılacak yazılım metrikleri gözden geçirilmiştir. [2]. Bu metrik grubunun nesne tabanlı yazılımlar için hatalı sınıfı bulmada önemli olduğu tespit edilmiştir [10] ve literatürde sıklıkla yazılım kalitesi ölçme amacıyla kullanılmaktadır [11]. Bu metrikler özgün olarak nesne tabanlı yazılımların kalitesini kaynak koddan ölçmek için önerilmiş olmalarına rağmen literatürde UML modellerine uygulanabilirliğini gösteren çalışmalar mevcuttur [12].
Metrik isimleri ve tanımları şu şekilde verilmiştir: [14]. Durum grafikleri bir sınıfın dinamik davranışını temsil eder. Bu nedenle bir durum grafiğinin karmaşıklığı sınıfın karmaşıklığı ile yakından ilgilidir. Böylece, durum grafiği karmaşıklığı bir sınıfın hata yatkınlığını etkilemektedir [15].
Oyetoyan ve arkadaşları [17] farklı hata ölçümlerinin hataya yatkın yazılım bileşenlerini belirlemedeki rolünü tespit etmek için bir çalışma ortaya koymuşlardır. Bu çalışmada hata sayısı, hata yoğunluğu, hata önem derecesi ve hata düzeltme çabası olmak üzere dört farklı hata ölçümü karşılaştırılmıştır. Hata sayısı, bir yazılım bileşeninde tespit edilen toplam hata sayısıdır. Hata yoğunluğu, hata sayısının kod satır sayısına bölünmesi ile elde edilir. Hata önem derecesi, tespit edilen hatanın kritiklik seviyesidir. Hata düzeltme çabası ise yazılım bileşeninde tespit edilen hatanın düzeltilmesi için harcanan işçiliği ifade eder.
Aselsan Savunma Sistem Teknolojileri Sektör Başkanlığı Gömülü ve Gerçek Zamanlı Yazılım Tasarım Müdürlüğü (GGZYTM) bünyesinde geliştirilen yazılım bileşenleri organizasyonel olarak kabul edilmiş ve yayınlanmış yazılım referans mimarisine [18] göre geliştirilmektedir. Bu şekilde yazılım bileşenlerinin tasarım olgunluğu belli bir ölçüde garanti edilmektedir. Bununla birlikte, referans mimaride tanımlanan arayüzler dışında, bileşenler için sınırlı tasarım bilgisi bulunması nedeniyle yazılım bileşenlerinin kalitesinin geliştiriciye bağlı olduğu gözlenmiştir. Bu nedenle referans mimariyle uyumlu olarak geliştirilen yazılım bileşenleri için yapısal özelliklerin belirtilmesi yararlı olacaktır. Bu çalışmanın amacı, geliştirilecek olan yazılım bileşenlerinin kalite düzeyini artırmak ve hâlihazırda geliştirilmiş olan yazılım bileşenlerinin kalite düzeyini ortaya koymaktır. GGZYTM tarafından yazılım bileşenleri bir UML aracı kullanılarak geliştirildiği için yazılım metriklerini UML modellerinden toplamak önemlidir. Bu çalışmanın sonuçları daha yüksek kalitede yazılım bileşenleri geliştirmek için yazılım geliştiricilerine rehberlik etmek amacıyla kullanılacaktır. Bu çalışmada, bir yazılım bileşeninin hata yatkınlığı kalitesinin önemli bir göstergesi olarak kabul edilmiştir. GGZYTM tarafından geliştirilen projelere ait bazı yazılım bileşenleri seçilmiş ve bu bileşenlere ait tasarım metrikleri toplanmıştır. UML kullanılarak tasarlanan gömülü ve gerçek zamanlı yazılım bileşenlerinin hatalarının değerlendirilmesinde hangi tasarım metriğinin önemli olabileceğini bulmak için yazılım bileşenlerinin metrikleri ve hataları analiz edilmiştir.
Bu çalışma boyunca GGZYTM bünyesinde faaliyet gösteren bir yazılım geliştirme ekibiyle çalışılmıştır. Bu ekip, otomatik kod üretme yeteneği bulunan bir UML aracı ile C++ kullanarak atış kontrol sistemleri için yazılım geliştirmektedir. Atış kontrol sistemleri birçok algılayıcıdan gelen verileri işleyerek, en doğru zamanda en doğru atışı yapabilmek için gerekli işlemleri yapan sistemlerdir. Yazılım geliştirme çalışmaları sırasında Silah Sistemleri Referans Mimarisi (SSRM) [18] olarak adlandırılan bir referans mimari kullanılmaktadır. Referans mimarinin temel bileşenleri kısa açıklamalarıyla aşağıda verilmiştir.
Görevler proje gereksinimlerine göre farklılık gösteren senaryo işleticileridir. Yetenekler belirli bir görevi yerine getirmeyi amaçlar, örneğin; hedef yönetimi, platform yönetimi. Yetenekler yeniden kullanılabilir bileşenler olarak geliştirilmiştir. Yazılım Yöneticisi yazılımın durumuna göre hangi yazılım bileşeninin aktif olacağına karar verir. Referans mimarinin bu bileşeni projeye özeldir. Dış Arayüz sistemde bulunan kullanıcı arayüzünü, komuta kontrol arayüzünü, vs. temsil eder. Yazılımda böyle bir bileşen tanımlanmasının amacı dış ortamdaki değişkenliği yazılımdan ayırabilmektir. Sistem Çevresi sistemde bulunan algılayıcı ve eğleyicilerin servislerini yazılıma aktarmaktan sorumludur. İşletim Çevresi yazılımın donanım ve işletim sisteminden bağımsızlığını sağlar.
Yazılım ekibi içerisinde en fazla bileşen Sistem Çevresi Katmanı için geliştirilmiş ve hata sayısının en fazla bu katmanda olduğu tespit edilmiştir. Bu nedenle çalışma kapsamında incelenen yazılım bileşenlerinin hepsi referans mimarinin Sistem Çevresi Katmanından seçilmiştir. Yazılım bileşenleri, tamamlanmış ve müşteriye teslim edilmiş en az iki projede kullanılan bileşenler arasından seçilmiştir. Böylece araştırma konusu olacak yazılım bileşenlerinin yeterince test edilmiş bileşenler olması amaçlanmıştır. Sistem Çevresi Katmanında birçok yazılım bileşeni olmasına karşın bunlardan ancak 10 tanesi belirlenen ölçüte uymuştur.
Bu çalışmada kullanılacak yazılım metriklerini seçerken GGZYTM'nin gereksinimleri ve öncelikleri dikkate alınmıştır. Hangi metrik veya metrik setinin kullanılacağını belirlemek amacıyla literatür taranmış ve geniş bir metrik seti ölçüm alınacak projelerin yazılım geliştiricileri ile birlikte değerlendirilmiştir. Metrik seçimi gerekçeleriyle birlikte Tablo 1'de verilmiştir. "Metrik Seçimi" sütunu ilgili metriğin ölçülüp ölçülmeyeceğini belirtir, "+" işareti metriğin ölçüleceği, "-" işareti metriğin ölçülmeyeceği anlamına gelir. Bu bilgiler ışığında yazılım tasarım metriklerinin java eklentileri geliştirerek ölçülebileceği, bazı metrik ölçümleri için ise SDMetrics aracının kullanılabileceğine karar verilmiştir.
Yazılım bileşenlerine ait hata verilerinin elde edilmesinde Aselsan bünyesinde kullanılan hata takip aracının verileri kullanılmıştır. Bununla birlikte, hata kayıtlarının birçoğu sadece ilgili yazılım bileşeninin içinde yer aldığı projeyi adreslemekteydi. Bu noktada, ilgili yazılım bileşenine ait hata kayıtlarının ortaya çıkarılmasında projede çalışan yazılım geliştiricilerden destek alınmıştır.
Metrik ölçümleri, çoğunlukla yazılım geliştirme ekibi tarafından kullanılan UML aracı için geliştirilen java eklentisi kullanılarak elde edilmiştir. Bazı metrik ölçümleri içinse hazır araçlar kullanılmıştır. LCOM metriğini UML modelinden ölçen bir araç bulanamamıştır. Ayrıca java eklentisi ile de metrik ölçümü elde edilememiştir. Bu nedenle, LCOM metriği değerlendirmeden çıkarılmıştır.
Seçilen metrikler, Sınıf Diyagramı Metrikleri dışında, sınıf seviyesinde ölçülen metriklerdir. Bu nedenle, birden fazla sınıf içeren bileşenlerin metrik değerlerinin bir araya getirilmesi gerekmiştir. Bunun için [20]'de verilen yöntemden faydalanılmıştır. Yönteme göre, bileşen seviyesinde WMC, NOC ve RFC metrik değerleri toplanmalı, DIT için en yüksek değer kullanılmalı, CBO içinse bileşen içindeki sınıflara bağımlı harici sınıfların sayısı dikkate alınmalıdır. Durum grafiği metrikleri boyut ve karmaşıklık metrikleri olarak kabul edildiği için bireysel sınıfların metrik değerleri toplanmalıdır. Bunun sonucunda metrik ölçüm sonuçları Tablo 2'deki haliyle oluşmuştur. Hata Yoğunluğu 0,794 3,701 2,678 1,819 0,766 1,502 3,95 0 0,53 5,249
Hesaplanan yazılım metrik değerlerini hata yatkınlığı ile ilişkilendirmeden önce Tablo 2'ye baktığımızda DIT ve NOC değerleri için anlamlı sonuçlar alınamadığını görüyoruz. Bunun nedeni GGZYTM bünyesinde geliştirilen yazılım bileşenlerinde uygulama kalıtımından ziyade arayüz kalıtımı kullanılmasıdır. Bu nedenle, DIT ve NOC metrikleri kapsam dışında bırakılarak analizden çıkarılmıştır. Ayrıca DIT ve LCOM metriklerinin nesne tabanlı yazılımlar için kalite metriği olarak kullanılmasını eleştiren ve NOC metriğinin hata yatkınlığını tespit etmek için kullanılmaması gerektiğini ifade eden çalışmalar vardır [21]. Yazılım metrikleri ve hata yatkınlığı arasındaki ilişkiyi doğrulamak için ilk olarak Pearson ilişki katsayısı kullanılmıştır. Pearson ilişki katsayısının kullanılabilmesi için veriler içerisinde aykırı değer olmamalı ve veriler normal dağılım göstermelidir. Bu nedenle ilk önce veriler üzerinde aykırılık ve normallik testleri uygulanmıştır.
Bileşen_3 Normal Tablo 4'ten de görülebileceği gibi hata sayısı, hata önem derecesi ve hata düzeltme çabası verileri aykırı veri ve/veya normallik testlerinden geçememiş, sadece hata yoğunluğu verisi bu testlerden geçmiştir. Bu nedenle, istatistiksel anlamda daha anlamlı sonuçlar elde edebilmek için analize Spearman ilişki katsayısı ile devam edilmiştir.
Spearman ilişki katsayısı parametrik olmayan bir testtir ve dağılım normal olmadığında iki sürekli değişken arasındaki ilişkinin belirlenmesinde kullanılır. 0 ve +1 arasındaki değerler pozitif ilişkiyi, 0 ve -1 arasındaki değerler ise negatif ilişkiyi temsil eder. Bu test için sonuçlar Tablo 5'da verilmiştir. İki değişken arasındaki ilişki p değeri 0,05'in altındaysa (p<0,05) istatistiksel olarak anlamlıdır. İlişki katsayısının gücünün sınıflandırılması hakkında genel bir kural olmamasına rağmen, Cohen [22] ilişki katsayısının mutlak değeri 0,1 ile 0,3 arasındaysa ilişki gücü zayıf, ilişki katsayısının mutlak değeri 0,3 ile 0,5 arasındaysa ilişki gücü orta, ilişki katsayısının mutlak değeri 0,5'ten büyük ise ilişki gücü yüksek olarak tanımlamıştır. Bu bilgiler ışığında yazılım metriklerinin hata yatkınlığı ölçümleri ile ilişkisi Tablo 6'deki şekliye oluşmuştur.
NA, NCS --Tablo 6'deki istatiksel olarak anlamlı ilişkilere bakıldığında hata sayısı ile NA, NSS, NCS ve NT metrikleri yüksek ilişki göstermiştir.
Hata yoğunluğu ile sadece CBO metriği arasında ilişki olduğu tespit edilmiştir. Ayrıca CBO metriği diğer hata yatkınlık ölçümleri ile ilişki göstermemiştir. Buradan hata yoğunluğunun fazla olmasına neden olabilecek metrikler için anlamlı bir sonuç alınamadığı gözlenmektedir. Bunun nedeni, bu çalışma kapsamında incelenen yazılım bileşenlerinin çok değişken oranda yazılım kaynak kodu içermesi olabilir. Örneğin, Bileşen_3 3771 satır, Bileşen_9 23893 satır kaynak kod içermektedir. Literatürde büyük yazılım bileşenlerinin düşük hata yoğunluğu gösterme eğilimi olduğunu gösteren çalışmalar mevcuttur [23].
Hata önem derecesi için NA, NSS, NCS, NT metriklerine ek olarak RFC, NEntryA, NE ve CC metrikleri yüksek ilişki göstermiştir. Araştırma kapsamında incelenen 15 yazılım metriğinden 8'i hata önem derecesi ile yakından ilgili olduğu tespit edilmiştir.
Hata düzeltme çabası için ise sadece NA ve NCS metrikleri yüksek ilişki göstermiştir. Ayrıca bu iki metrik hata sayısı ve hata önem derecesi için de hata yatkınlık ölçümleri ile yakından ilişki içindedir. NA ve NCS metriklerinin hata sayısı, hata önem derecesi ve hata düzeltme çabası için doğrulanmış olması sonuçların tutarlılığını göstermektedir ancak hata düzeltme çabası için sadece iki metrik ile ilişkinin tespit edilmiş olması hata takip aracındaki hata düzeltme çabası kayıtlarının sübjektif olduğunu düşündürtmüştür.
Literatürde nesne tabanlı yazılımlara ait yapısal özelliklerin yazılım kalitesi üzerine etkilerini metriklerin kullanımıyla inceleyen çok sayıda çalışma bulunmaktadır. Bu çalışmalar yazılım tasarım metrikleri ile yazılım hata yatkınlığı arasında güçlü bir ilişki olduğunu doğrulamıştır. Ancak bu çalışmaların önemli bir kısmı yazılım tasarım metriklerini yazılım kaynak kodundan ölçmektedir. UML modellerinden toplanan metrikler ile yazılım hata yatkınlığı arasındaki ilişkiyi inceleyen çalışmaların azlığı bu çalışmanın temel motivasyonunu oluşturmuştur. Çalışma kapsamında Aselsan bünyesinde geliştirilen 10 yazılım bileşeni incelenmiştir. Literatür araştırması ile ortaya çıkarılan tasarım metrikleri yazılım bileşenlerinin UML modellerinden ölçülmüştür. Hata yatkınlık ölçümleri ise kurum içerisinde kullanılan hata takip aracından elde edilmiştir. Yazılım metrikleri ve hata yatkınlık ölçümleri arasında istatistiksel olarak anlamlı bir ilişki bulabilmek için öncelikle Pearson ilişki katsayısı kullanılmıştır. İncelenen bir takım verilerin ayrık veri içermesi ve normal dağılım göstermemesi sebebiyle analize Spearman ilişki katsayısı ile devam edilmiştir. Analiz sonucunda 15 yazılım metriğinin 9 tanesinin bir veya daha fazla hata yatkınlık ölçümü ile istatistiksel olarak anlamlı ilişki gösterdiği tespit edilmiştir.
Yapılan çalışma sonucunda hata yatkınlığı ile ilişkilendirilen yazılım tasarım metriklerinin gelecek çalışmalar için hatalı yazılım bileşenlerini tahmin etmede kullanılabileceği değerlendirilmektedir. Böylece hataya yatkın olduğu tahmin edilen yazılım bileşenleri için daha fazla kod gözden geçirme, statik kod analizi ve birim test işçiliği harcanarak karşılaşılabilecek hataların önüne geçilebilir.
Ayrıca tasarım metrikleri UML modellerinden ölçüldüğü için henüz kaynak kod üretilmemişken tasarlanan yazılımların kalitesi hakkında öngörü sahibi olunabilir. Ancak yazılım modellerinin soyutlama seviyesinin yüksek olduğu durumlar göz önünde bulundurulmalıdır.
Çalışma kapsamında kısıtlı sayıda yazılım bileşeninin incelenmiş olması, incelenen yazılım bileşenlerinin tek bir yazılım ekibi içerisinde geliştirilmiş olması ve tüm yazılım bileşenlerinin atış kontrol alanına ait olması çalışma sonuçlarının genellenebilirliğini kısıtlamaktadır.
Sonuç olarak, bu çalışmada UML kullanılarak geliştirilen nesne tabanlı yazılımlara ait tasarım metrikleri ile hata yatkınlığı arasındaki ilişki gömülü ve gerçek zamanlı yazılımlar bağlamında gerçek proje verileri kullanılarak analiz edilmiştir.