=Paper=
{{Paper
|id=Vol-2201/UYMS_2018_paper_35
|storemode=property
|title=Nesne Tabanli Yazilimlarin Yapisal Ozelliklerinin Hata Yatkinligi Uzerine Etkilerinin Incelenmesi(Investigation of the Effects of Structural Characteristics of Object-Oriented Software on Fault-Proneness)
|pdfUrl=https://ceur-ws.org/Vol-2201/UYMS_2018_paper_35.pdf
|volume=Vol-2201
|authors=Halit Golcuk
}}
==Nesne Tabanli Yazilimlarin Yapisal Ozelliklerinin Hata Yatkinligi Uzerine Etkilerinin Incelenmesi(Investigation of the Effects of Structural Characteristics of Object-Oriented Software on Fault-Proneness)==
https://ceur-ws.org/Vol-2201/UYMS_2018_paper_35.pdf
Nesne Tabanlı Yazılımların Yapısal Özelliklerinin Hata
Yatkınlığı Üzerine Etkilerinin İncelenmesi
Halit Gölcük
Gömülü ve Gerçek Zamanlı Yazılım Tasarım Müdürlüğü, SST Sektör Bşk.
ASELSAN A.Ş.
hgolcuk@aselsan.com.tr
Özet. Modelleme dillerinin Yazılım Mühendisliği alanında kullanımının artma-
sı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 ka-
litesini ölçebilmek için öncelikle o yazılım ürününden kalite anlamında ne bek-
lendiği ortaya konulmalıdır. Bu çalışma, Birleşik Modelleme Dili (UML) kulla-
nılarak geliştirilen nesne tabanlı yazılımların model seviyesinde gözlenebilen
bazı yapısal özelliklerinin yazılım kalitesi üzerine etkilerini incelemektedir. Ya-
zılım kalitesi yazılımın hata yatkınlığı olarak tanımlanmıştır. Çalışma kapsa-
mı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 tasa-
rım metrikleri ve hata yatkınlık metrikleri arasındaki ilişki istatistiksel olarak
doğrulanmıştır.
Anahtar Kelimeler: Yazılımın yapısal özellikleri, UML metrikleri, Yazılım
kalitesi, Hata yatkınlığı, Deneysel çalışma.
Investigation of the Effects of Structural Characteristics
of Object-Oriented Software on Fault-Proneness
Abstract. With the increasing use of modeling languages in Software Engineer-
ing, it has become important to measure and control the quality of a software
model, not just the software source code. However, in order to measure the
quality of a software product, it is first necessary to determine the expectations
from the software product in terms of quality. This study examines the effect of
some structural features observed at the model level on software quality of ob-
ject-oriented software developed using the Unified Modeling Language (UML).
Software quality is defined as fault-proneness. Embedded and real-time soft-
ware components developed in Aselsan are analyzed. The correlation between
software design metrics that reflect structural characteristics of software com-
ponents and measured through UML models and fault-proneness metrics of
these components are presented. The correlation between software design met-
rics and fault-proneness metrics is statistically verified.
Keywords: Structural software characteristics, UML metrics, Software quality,
Fault-proneness, Empirical study.
1 Giriş
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ös-
tergedir. 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 et-
mek 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 ge-
liştirilen atış kontrol yazılımlarına aittir. Bütün metrikler incelenen yazılım bileşenle-
rinin 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 ka-
liteyi 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.
2 Literatür
2.1 Yazılım Kalite Ölçümü
Farklı özelliklerdeki yazılım ürünleri için farklı kalite hedefleri öne çıkmaktadır. Ör-
neğ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şıla-
yan 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 mode-
lini kullanmaktır. Ancak, bu tür kalite modelleri soyut kalmakta ve uyarlamada sıkın-
tı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.
2.2 Yazılım Kalite Metrikleri
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 kay-
nak 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.
CK Metrikleri [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:
Weighted Methods per Class (WMC): Sınıf içerisinde tanımlanmış metotların
karmaşıklık değerinin toplamıdır.
Depth of Inheritance Tree (DIT): Kalıtım hiyerarşisindeki kalıtım derinliğini ölçer.
Number of Children (NOC): Herhangi bir temel sınıftan direkt olarak türetilmiş
sınıf sayısını verir.
Coupling between Objects (CBO): Sınıflar arasındaki bağımlılığın ölçümüdür.
Response for a Class (RFC): Bir sınıfa gönderilen mesaja karşılık o sınıftan çağırı-
lan metot sayısıdır.
Lack of Cohesion in Methods (LCOM): Bir sınıf içindeki metotların bağımlılığına
dair bir ölçümdür.
Sınıf Diyagram Metrikleri [13]. Genero ve arkadaşları [13] bu metrikleri UML sınıf
diyagramları için deneysel olarak doğrulamışlardır.
Number of Associations (NAssoc): Sınıf diyagramı içindeki ilişki sayısıdır.
Number of Aggregation (NAgg): Sınıf diyagramı içindeki içerim sayısıdır.
Number of Dependencies (NDep): Sınıf diyagramı içindeki bağımlılık sayısıdır.
Number of Generalizations (NGen): Sınıf diyagramı içindeki genelleme sayısıdır.
Number of Aggregations Hierarchies (NAggH): Sınıf diyagramı içindeki içerim
hiyerarşisi sayısıdır.
Number of Generalizations Hierarchies (NGenH): Sınıf diyagramı içindeki genel-
leme hiyerarşisi sayısıdır.
Maximum DIT (MaxDIT): Sınıf diyagramı içindeki kalıtım hiyerarşisinin maxi-
mum derinliğidir.
Maximum HAgg (MaxHAgg): Sınıf diyagramı içindeki içerim hiyerarşisinin
maximum derinliğidir.
Number of Classes (NC): Sınıf diyagramı içindeki sınıf sayısıdır.
Number of Attributes (NA): Sınıf diyagramı içindeki nitelik sayısıdır.
Number of Methods (NM): Sınıf diyagramı içindeki metot sayısıdır.
Durum Grafiği (Statechart) Metrikleri [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 yat-
kınlığını etkilemektedir [15].
Number of Entry Actions (NEntryA): Durum grafiğindeki giriş eylemi sayısıdır.
Number of Exit Actions (NExitA): Durum grafiğindeki çıkış eylemi sayısıdır.
Number of Activities (NAc): Durum grafiğindeki aktivite sayısıdır.
Number of Simple States (NSS): Durum grafiğindeki basit durum sayısıdır.
Number of Composite States (NCS): Durum grafiğindeki karma durum sayısıdır.
Number of Guards (NG): Durum grafiğindeki koruma koşulu sayısıdır.
Number of Events (NE): Durum grafiğindeki olay sayısıdır.
Number of Transitions (NT): Durum grafiğindeki geçiş saysıdır.
Cyclomatic Complexity (CC): McCabe [16] tarafından önerilen karmaşıklık birimi
|NT-NS+2| olarak uyarlanmıştır.
2.3 Hata Yatkınlığı Ölçüm Yöntemleri
Oyetoyan ve arkadaşları [17] farklı hata ölçümlerinin hataya yatkın yazılım bileşenle-
rini 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 seviyesi-
dir. Hata düzeltme çabası ise yazılım bileşeninde tespit edilen hatanın düzeltilmesi
için harcanan işçiliği ifade eder.
3 Yöntem
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şenleri-
nin 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üze-
yini ortaya koymaktır. GGZYTM tarafından yazılım bileşenleri bir UML aracı kulla-
nılarak geliştirildiği için yazılım metriklerini UML modellerinden toplamak önemli-
dir. 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öster-
gesi 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.
3.1 Yazılım Ekibi Tarafından Kullanılan Referans Yazılım Mimarisi
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ışma-
ları 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.
3.2 Araştırma Konusu Yazılım Bileşenleri
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 kap-
samı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 edil-
miş 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 bunlar-
dan ancak 10 tanesi belirlenen ölçüte uymuştur.
3.3 Seçilen Yazılım Tasarım Metrikleri
Bu çalışmada kullanılacak yazılım metriklerini seçerken GGZYTM’nin gereksinimle-
ri 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 projele-
rin 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ütu-
nu 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.
Tablo 1. Metrik Seçimi
Metrik Seti Metrik Metrik Yorum
Seçimi İsmi
CK Metrikleri + WMC Bu metrik seti bir sınıfın hataya yatkınlı-
+ DIT ğını belirlemede iyi bir gösterge olarak
+ NOC kabul edilmiştir.
+ CBO
+ RFC
+ LCOM
Sınıf Diyagramı - NAssoc GGZYTM bünyesinde geliştirilen yazı-
Metrikleri lımlarda sınıflar arası ilişkiler UML
portları üzerinden kurulmaktadır.
- NAgg GGZYTM bünyesinde geliştirilen yazı-
- NAggH lımlarda içerim ilişkisi kurulmamaktadır.
- MaxHAgg
- NGen GGZYTM bünyesinde geliştirilen yazı-
- NGenH lımlarda uygulama kalıtımından ziyade
arayüz kalıtımı kullanılmaktadır.
- MaxDIT CK Metrik setinde DIT metriği bulundu-
ğu için bu metriğin ölçülmesinin gerekli
olmadığı değerlendirilmiştir.
- NDep GGZYTM bünyesinde geliştirilen yazı-
lımlar sadece referans mimariye bağım-
lıdır.
+ NC Bir yazılım bileşeninin boyutu ile hata
+ NA yatkınlığı arasında bir ilişki olması bek-
+ NM lenmektedir.
Durum Grafiği + NEntryA Bir sınıfın durum grafiğinin yapısal kar-
Metrikleri + NExitA maşıklığı ile hata yatkınlığı arasında bir
+ NAc ilişki olması beklenmektedir.
+ NSS
+ NCS
+ NG
+ NE
+ NT
+ CC
Çalışma kapsamında ölçülecek metrikler seçildikten sonra bu metriklerin ölçüm yön-
temleri değerlendirilmiştir. Metrik ölçümlerinin hazır bir araç ile yapılıp yapılamaya-
cağını görmek için literatür gözden geçirilmiş ve bu amaçla kullanılabilecek
SDMetrics [19] ön plana çıkmıştır. SDMetrics, UML modellerini XMI formatında
dışa aktarım yeteneği bulunan UML araçları ile birlikte kullanılabilmektedir.
Yazılım geliştirme ekibi tarafından kullanılan UML aracına java eklentileri ile yeni
özellikler katılabilmektedir. Bu sayede çalışma ihtiyaçlarını göz önünde bulundurarak
metrik ölçümünün otomatikleştirilebileceği değerlendirilmiştir.
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.
3.4 Yazılım Bileşenlerine ait Hata Verileri
Yazılım bileşenlerine ait hata verilerinin elde edilmesinde Aselsan bünyesinde kulla-
nı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.
4 Bulgular
4.1 Metrik Ölçüm Sonuçları
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 ek-
lentisi ile de metrik ölçümü elde edilememiştir. Bu nedenle, LCOM metriği değerlen-
dirmeden çı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 toplan-
malıdır. Bunun sonucunda metrik ölçüm sonuçları Tablo 2’deki haliyle oluşmuştur.
Tablo 2. Metrik Ölçüm Sonuçları
Bileşen_10
Bileşen_1
Bileşen_2
Bileşen_3
Bileşen_4
Bileşen_5
Bileşen_6
Bileşen_7
Bileşen_8
Bileşen_9
WMC 143 236 238 201 251 269 233 64 117 260
DIT 0 0 0 1 1 0 0 0 0 0
NOC 0 0 0 0 0 0 0 0 0 0
CBO 12 12 15 12 12 17 16 10 10 16
RFC 29 30 66 37 47 67 27 20 26 26
NC 1 1 5 3 3 5 1 4 1 1
NA 26 41 117 48 46 79 21 22 12 34
NM 35 26 61 68 50 76 23 25 13 20
NEntryA 16 24 88 38 35 22 4 5 6 5
NExitA 3 1 11 5 2 4 0 2 0 0
NAc 29 15 93 27 27 41 3 3 7 5
NSS 16 21 88 41 37 24 10 4 6 4
NCS 10 14 34 36 33 11 7 3 4 4
NG 11 8 84 29 31 13 1 2 1 0
NE 26 31 105 57 55 26 14 4 5 3
NT 37 48 193 98 91 47 21 7 8 6
CC 13 15 75 25 25 18 6 2 0 0
4.2 Hata Yatkınlık Ölçüm Sonuçları
Yazılım bileşenleri ile ilgili hatalar ölçümlerin alındığı projelerde çalışan yazılım
mühendisleri yardımıyla elde edilmiştir. Bu kapsamda yaklaşık 2500 hata kaydı ince-
lenmiş, bunlardan 184’ünün araştırma konusu yazılım bileşenlerine ait olduğu tespit
edilmiştir. Her bir yazılım bileşeni için hata yatkınlık ölçüm sonuçları Tablo 3’te ve-
rilmiştir.
Tablo 3. Hata Yatkınlık Metrikleri Ölçüm Sonuçları
Bileşen_10
Bileşen_1
Bileşen_2
Bileşen_3
Bileşen_4
Bileşen_5
Bileşen_6
Bileşen_7
Bileşen_8
Bileşen_9
Hata Sayısı 5 24 64 26 11 17 15 0 2 20
Hata Yoğunluğu 0,794 3,701 2,678 1,819 0,766 1,502 3,95 0 0,53 5,249
Hata Önem 14 76 232 79 34 58 55 0 7 58
Derecesi
Hata Düzeltme 7 88 206 63 17 33 22 0 1 45
Çabası
4.3 Yazılım Bileşenlerinin Yazılım Metrikleri ve Hata Yatkınlığı Arasındaki
İlişki
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üyo-
ruz. 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 metrik-
leri kapsam dışında bırakılarak analizden çıkarılmıştır. Ayrıca DIT ve LCOM metrik-
lerinin 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.
Tablo 4. Aykırılık ve Normallik Testi Sonuçları
Aykırı Veri Normallik
Hata Sayısı Bileşen_3 Normal
Hata Yoğunluğu - Normal
Hata Önem Derecesi Bileşen_3 Normal Değil
Hata Düzeltme Çabası 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 ara-
sı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.
Tablo 5. Yazılım Metrikleri ve Hata Yatkınlığı Arasındaki Spearman İlişki Katsayısı
Hata Yoğunlu- Hata Önem Hata Düzeltme
Hata Sayısı
ğu Derecesi Çabası
0,552 0,539 0,559 0,576
WMC p = 0,098 p = 0,108 p = 0,093 p = 0,082
0,529 0,717 0,540 0,529
CBO p = 0,116 p = 0,019 p = 0,107 p = 0,116
0,596 0,140 0,643 0,584
RFC p = 0,069 p = 0,700 p = 0,045 p = 0,077
0,221 -0,299 0,264 0,176
NC p = 0,539 p = 0, 401 p = 0,460 p = 0,627
0,745 0,224 0,722 0,721
NA p = 0,013 p = 0,533 p = 0,009 p = 0,019
0,479 -0,055 0,529 0,430
NM p = 0,162 p = 0,881 p = 0,116 p = 0,214
0,614 -0,049 0,637 0,590
NEntryA p = 0,059 p = 0,894 p = 0,048 p = 0,073
0,431 -0,178 0,469 0,369
NExitA p = 0,214 p = 0,622 p = 0,171 p = 0,294
0,463 -0,049 0,502 0,445
NAc p = 0,177 p = 0,894 p = 0,140 p = 0,197
0,650 0,085 0,686 0,614
NSS p = 0,042 p = 0,815 p = 0,029 p = 0,059
0,729 0,213 0,753 0,693
NCS p = 0,017 p = 0,555 p = 0,012 p = 0,026
0,413 -0,207 0,451 0,377
NG p = 0,235 p = 0,567 p = 0,191 p = 0,283
0,620 0,061 0,649 0,596
NE p = 0,056 p = 0,868 p = 0,042 p = 0,069
0,636 0,067 0,669 0,612
NT p = 0,048 p = 0,855 p = 0,035 p = 0,060
0,604 0,049 0,639 0,573
CC p = 0,065 p = 0,894 p = 0,047 p = 0,083
İki değişken arasındaki ilişki p değeri 0,05’in altındaysa (p<0,05) istatistiksel ola-
rak 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ın-
daysa 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.
Tablo 6. Yazılım Metrikleri ve Hata Yatkınlığı Arasındaki İstatiksel Olarak Anlamlı İlişki
Yüksek Orta Düşük
Hata Sayısı NA, NSS, NCS, NT - -
Hata Yoğunluğu CBO - -
RFC, NA, NEntryA,
Hata Önem Derecesi NSS, NCS, NE, NT, - -
CC
Hata Düzeltme Çabası 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. Ay-
rı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öste-
ren ç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öster-
miş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.
5 Değerlendirme ve Sonuç
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 incelen-
miştir. Literatür araştırması ile ortaya çıkarılan tasarım metrikleri yazılım bileşenleri-
nin 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 Pe-
arson 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 de-
vam 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 edil-
miştir.
Yapılan çalışma sonucunda hata yatkınlığı ile ilişkilendirilen yazılım tasarım met-
riklerinin gelecek çalışmalar için hatalı yazılım bileşenlerini tahmin etmede kullanıla-
bileceğ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.
Kaynaklar
1. Kaur, A., Sandhu, P.S., Bra, A.S.: Early Software Fault Prediction Using Real Time Defect
Data. In: 2009 Second International Conference on Machine Vision. IEEE (2009).
2. Chidamber, S.R., Kemerer, C.F.: A metrics suite for object oriented design. IEEE Transac-
tions on Software Engineering. 20, 476-493 (1994).
3. Nugroho, A., Chaudron, M.R.V., Arisholm, E.: Assessing UML design metrics for predict-
ing fault-prone classes in a Java system. In: 2010 7th IEEE Working Conference on Min-
ing Software Repositories (MSR 2010). IEEE (2010).
4. Hneif, M., Lee, S.P.: Using Guidelines to Improve Quality in Software Nonfunctional At-
tributes. IEEE Software. 28, 72–77 (2011).
5. Klas, M., Lampasona, C., Munch, J.: Adapting Software Quality Models: Practical Chal-
lenges, Approach, and First Empirical Results. In: 2011 37th EUROMICRO Conference
on Software Engineering and Advanced Applications. (2011).
6. Nakai, H., Tsuda, N., Honda, K., Washizaki, H., Fukazawa, Y.: A SQuaRE-based software
quality evaluation framework and its case study. In: 2016 IEEE Region 10 Conference
(TENCON). IEEE (2016).
7. Zhang, B., Shen, X.: The effectiveness of real-time embedded software testing. In: The
Proceedings of 2011 9th International Conference on Reliability, Maintainability and Safe-
ty. IEEE (2011).
8. Brito e Abreu, F.: The MOOD Metrics Set. ECOOP’95 Workshop on Metrics (1995).
9. Lorenz, M., Kidd, J.: Object-oriented software metrics. Prentice-Hall, Englewood Cliffs,
N.J. (1994).
10. Srivastava, S., Kumar, R.: Indirect method to measure software quality using CK-OO
suite. In: 2013 International Conference on Intelligent Systems and Signal Processing
(ISSP). IEEE (2013).
11. Binanto, I., Warnars, H.L.H.S., Gaol, F.L., Abdurachman, E., Soewito, B.: Measuring the
quality of various version an object-oriented software utilizing CK metrics. In: 2018 Inter-
national Conference on Information and Communications Technology (ICOIACT). IEEE
(2018).
12. McQuillan, J.A., Power, J.F.: On the Application of Software Metrics to UML Models. In:
Models in Software Engineering. pp. 217–226. Springer Berlin Heidelberg (2007).
13. Genero, M., Piattini, M., Calero, C.: Empirical validation of class diagram metrics. In:
Proceedings International Symposium on Empirical Software Engineering. (2002).
14. Cruz-Lemus, J., Maes, A., Genero, M., Poels, G., Piattini, M.: The impact of structural
complexity on the understandability of UML statechart diagrams. Information Sciences.
180, 2209-2220 (2010).
15. Wagner, S., Jürjens, J.: Model-Based Identification of Fault-Prone Components. In: De-
pendable Computing - EDCC 5. pp. 435–452. Springer Berlin Heidelberg (2005).
16. McCabe, T.J.: A Complexity Measure. IEEE Transactions on Software Engineering. SE-2,
308-320 (1976).
17. Oyetoyan, T.D., Conradi, R., Cruzes, D.S.: A Comparison of Different Defect Measures to
Identify Defect-Prone Components. In: 2013 Joint Conference of the 23rd International
Workshop on Software Measurement and the 8th International Conference on Software
Process and Product Measurement. IEEE (2013).
18. Kahraman, E., İpek, T., İyidir, B., Bazlamaçcı, C.F., Bilgen, S.: Bileşen Tabanlı Yazılım
Ürün Hattı Geliştirmeye Yönelik Alan Mühendisliği Çalışmaları. In: UYMS’09, pp. 283–
287 (2009).
19. Wüst, J.: SDMetrics - the design quality metrics tool for UML models,
https://www.sdmetrics.com. Accesed 2013/03/15.
20. Vernezza, T., Granatella, G., Succi, G., Benedicenti, L., Mintchev, M.: Defining metrics
for software components. In: World Multi-Conference on Systematics, Cybernetics and In-
formatics. pp. 16-23 (2000).
21. Bansal, M., Agrawal, C.P.: Critical Analysis of Object Oriented Metrics in Software De-
velopment. In: 2014 Fourth International Conference on Advanced Computing & Commu-
nication Technologies. IEEE (2014).
22. Muller, K., Cohen, J.: Statistical Power Analysis for the Behavioral Sciences. Technomet-
rics. 31, 499 (1989).
23. Ostrand, T.J., Weyuker, E.J.: The distribution of faults in a large industrial software sys-
tem. ACM SIGSOFT Software Engineering Notes. 27, 55 (2002).