Yazılım Metriklerini Kullanarak Düşük Kaliteli / Yüksek Riskli Modüllerin Otomatik Tespiti

Transkript

1 Yazılım Metriklerini Kullanarak Düşük Kaliteli / Yüksek Riskli Modüllerin Otomatik Tespiti Automatic Detection of Low Quality / High-Risk Modules by using Software Metrics Çağatay, ÇATAL TÜBİTAK-Marmara Araştırma Merkezi Bilişim Teknolojileri Enstitüsü, Kocaeli cagatay.catal@bte.mam.gov.tr Banu, DİRİ Bilgisayar Mühendisliği, Yıldız Teknik Üniversitesi, İstanbul banu@ce.yildiz.edu.tr Özet Yazılım sistemlerinde kusurların çok büyük bölümü, az sayıda modül üzerinde gerçekleşir ve kusur taşıyan modüllerin yüzdesinin %10 - %20 arasında değiştiği deneysel çalışmalarda tespit edilmiştir. Bu deneysel bilgiden hareketle, kusur eğilimli modüllerin test aşamasından önce belirlenip test kaynaklarının bu modüllere odaklandırılması, ürünün sahada çıkacak kusurlarını en düşük seviyeye indirecektir. Düşük kaliteli veya yüksek riskli olarak ifade edilebilen bu tür modüller, bazı yazılım araçları ile otomatik olarak belirlenebilmektedir. Bu çalışmada, yazılım metriklerini ve bu metriklerin eşik seviyelerini kullanarak yüksek riskli modüllerin nasıl belirlenebileceği ticari bir araç üzerinden açıklanmaktadır. Linux kaynak kodları içerisindeki selinux (security-enhanced linux) dizini, Predictive isimli araç ile incelenmiş ve yüksek riskli, orta riskli modüller saptanmıştır. Bu çalışmada, uygulayıcıların günlük yazılım geliştirmelerinde kullanabilecekleri metrikler açıklanarak kusur kestirim çalışmalarında yeterli olacak metrik kümeleri açıklanmıştır. Yüksek riskli modüller, metriklere ilişkin eşik seviyelerinin aşıldığı modüller olarak saptanmış olup, kusur kestirim modelleri bu çalışmada uygulanmamıştır. Önerilen metrikler, üzerinde çalıştığımız araştırma projesinde kullanılacaktır. Abstract Most of the faults occur in few modules of software systems and it has been identified that percentages of faulty modules are between 10% and 20% according to the experimental studies. Identification of fault-prone modules before testing phase and allocation of testing resources to these modules will minimize the operational errors that will occur in the field. These modules called low quality or high-risk modules can be identified automatically by software tools. In this study, it is explained how to identify high-risk modules by using software metrics and threshold levels on a commercial tool. selinux directory in Linux sources have been examined with Predictive and high-risk, medium-risk modules have been identified. In this study, software metrics that can be used by practitioners in their daily software development activities and metric suites that can be used for fault prediction have been detected. High-risk modules have been identified by using threshold levels and fault prediction models have not been used in this study. Suggested metrics will be used for our current research project. 1. Giriş Yazılım metrikleri ilk kez 1970 lerde önerilmiş olup halen üzerinde araştırmalar sürdürülmektedir. Thomas McCabe [1] ve Maurice Halstead [2] isimli araştırmacılar, 1970 lerde yapısal programlama dilleri için metot bazında bazı metrikleri ortaya koymuştur. Bu alandaki ilk kitap, Tom Gilb tarafından 1976 yılında Yazılım Metrikleri ismiyle yayımlanmıştır [3]. Geçen 40 yıla rağmen yazılım mühendislerinin metrikleri kullanarak yazılım geliştirme pratiklerini şekillendirdiklerini söylemek mümkün değildir da önerilen çevrimsel karmaşıklık (cyclomatic complexity) metriği hemen hemen tüm yazılım mühendisliği kitaplarında açıklanan bir metrik olmasına rağmen, birçok yazılım geliştirici tarafından hala bilinmemektedir ve eşik seviyeleri konusunda çoğu geliştiricinin yeterli bilgisi yoktur. Yazılım metriklerinin ulaştığı olgunluk sayesinde artık uygulayıcıların bu metriklerden günlük yazılım geliştirme faaliyetleri sırasında yararlanması gerekmektedir. Yazılım geliştirme ortamlarının (IDE vb.) bu tür metrikleri hesaplama konusundaki yetersizlikleri sebebiyle, bu zamana kadar uygulayıcılar bu metriklerden uzak kalmıştı. Ancak son yıllarda birçok tümleşik geliştirme ortamı bu tür metrikleri uyumlu ekler (plug-in) ya da doğrudan tümleşik geliştirme ortamı içerisinde hesaplamaya imkân vermektedir. Bu nedenle uygulamaya geçmesi için iyi

2 bir ortamın oluştuğunu ancak yeterli ilginin mevcut olmadığını söyleyebiliriz. Bu tür araçlar incelendiğinde, hesaplanan metriklerin oldukça farklı kümelerden oluştuğunu ve uygulayıcıların seçmesi gereken metrikleri bilemediğini söyleyebiliriz. Microsoft firmasının Visual Studio 2008 (Orcas) geliştirme ortamı içerisinde, 5 adet kod metriği hesaplanmaktadır. Bu sürümden önce, bu metrikler ürün içerisinde yer almıyordu. Son durumda üründe hesaplanabilen metrikler; kod satır sayısı, sınıf bağlılığı (class coupling), kalıtım derinliği (depth of inheritance), çevrimsel karmaşıklık ve bakım yapılabilirlik (maintainability) indeksidir. Bu büyük ölçekli ürün içerisinde bile sadece bu metrikler hesaplanabilmektedir ancak uygulayıcıların işine yarayabilecek metrikler bu 5 metrik ile sınırlı değildir. Bu çalışmada, uygulayıcıların kullanabilecekleri metrikler ayrıntıları ile birlikte açıklanmakta, eşik seviyelerinin aşıldığı metotlar yüksek riskli ve düşük kaliteli olarak ifade edilmektedir. Eşik seviyesi 1 ve eşik seviyesi 2 olarak ifade edebileceğimiz bu değerler; modülün orta riskli ya da yüksek riskli olarak 2 ayrı gruba ayrılmasını sağlamaktadır. 2. eşik seviyesinin değeri 1. değerden daha yüksektir ve 2. değerin geçilmesi durumunda modülün o metriğe göre yüksek riskli olduğu ifade edilir. Bu çalışmada ayrıca, linux çekirdeğinin sürümünde yer alan, güvenliği iyileştirilmiş linux (security-enhanced linux) dizinindeki kodlar, metrik ve eşik seviyeleri açısından incelenmiştir. İncelenen kaynak kodların %2 sinin yüksek riskli, %5 inin orta düzeyde riskli ve geride kalan %93 ünün düşük riskli olduğu belirlenmiştir. Riske neden olan metrikler ve detayları takip eden bölümlerde açıklanacaktır. Karmaşıklık, güvenliğin en büyük düşmanı olduğu açık bir gerçektir. Bu nedenle, bu tür yazılımların güvenli olabilmesi için yazılımların karmaşıklık metrikleri de dikkate alınarak geliştirilmesi gerekir. Örneğin; çevrimsel karmaşıklığı 100 ün üzerinde olan bir yönteme sahip bir yazılımı ele alalım. Sadece bu yöntem, 100 bağımsız yola sahiptir ve her birinin ayrı ayrı test edilmesi gerekir. Metotlardaki anahtar sözcüklerden if, while, &&,, switch deki her bir case, bu karmaşıklığı sayısal olarak 1 arttırmaktadır. Yazılım geliştirme sürelerini dikkate aldığımız zaman, her zaman test aşaması yeterli bütçeye ve zamana sahip olmayabilir. Bu durumlarda, yazılım modüllerinin tüm bağımsız yolları test edilmeden piyasaya sürülmesi gerekebilir. Bunun neticesinde bu tür yazılımlarda çok fazla açık bulunacağı için güvenliğin sağlanması oldukça zor olacaktır. Yazılım kusur kestirimi çalışmalarında, çoğunlukla önceki yazılım sürümünün metrikleri ve kusur bilgileri kullanılarak bir model ortaya çıkarılır, ardından yeni sürümdeki metriklere bağlı olarak modelden modüllerin yeni kusur eğilimlilik bilgisi elde edilmeye çalışılır. Modellerin oluşturulabilmesi için makine öğrenmesi tabanlı algoritmalar ya da istatistiksel yöntemler kullanılabilmektedir. Makine öğrenmesi kapsamında genetik algoritmalar, yapay sinir ağları, karar ağaçları gibi farklı yöntemler kullanılmıştır. Yaptığımız önceki çalışmalarda, Yapay Bağışıklık Sistem paradigmasından esinlenen yöntemler geliştirdik [4], [5]. Bu çalışmada, kusur kestirim modelleri yerine metriklerin eşik seviyelerine bağlı olarak modüllerin kusur eğilimliliği ve riski belirlenmektedir. Bu nedenle, kusur kestirim modelleri konusunda kapsamlı bilgi bu çalışmada verilmeyecektir. Bir sonraki bölümde, metot ve sınıf seviyesindeki yazılım metrikleri açıklanmaktadır. 3. bölümde üzerinde inceleme yapılan SELinux projesinin çıkışı ve kapsamı ortaya konulmaktadır. 4. bölümde durum çalışması, yüksek riskli olarak belirlenen modüller ve yüksek riske neden olan metrikler ifade edilmektedir. 5. bölümde sonuç ve gelecek çalışmalar açıklanmaktadır. 2. Yazılım Metrikleri Metrikleri, sınıf seviyesinde ve metot seviyesinde metrikler olarak iki ayrı grupta ele almak mümkündür. Sınıf seviyesindeki metrikler sadece nesneye yönelik programlama dilleri kullanıldığı durumda uygulanabilirken, metot seviyesindeki metrikler yapısal ve nesneye yönelik programlama dillerinde kullanılabilir. Durum çalışmasında, C programlama dili ile yazılmış SELinux kaynak kodları kullanıldığından sınıf seviyesindeki metrikler hesaplanmamıştır. Predictive aracı, metot seviyesindeki metriklerin eşik seviyelerine bağlı olarak ilgili metotu orta / düşük / yüksek riskli olarak işaretlemektedir. Sadece bir metrikte eşik seviyesinin geçilmesi, o metotun orta ya da yüksek riskli olarak gösterilmesi için yeterlidir. Bu yaklaşım elimizde hiç kusur verisi olmadığı durumlarda kullanılabilecek pratik bir yöntem gibi görülebilir ancak daha doğru modelleri kurgulamak için kusur kestirim modellerinden yararlanılması gerekmektedir. Bu noktada bir önceki yazılım sürümünün test aşamasında saptanmış kusur bilgilerine ihtiyaç olacaktır Sınıf Seviyesindeki Metrikler Sınıf seviyesindeki metriklerden en bilinenleri 1994 yılında Chidamber-Kemerer isimli araştırmacılar tarafından önerilmiş CK metrikleridir. Bu metrikler; WMC, CBO, LCOM, RFC, DIT, NOC kısaltmaları ile bilinmektedir. Predictive aracı bu metriklerin hepsini sınıf bazında hesaplayabilmektedir. Bu metriklere ek olarak bu araç; public metotların sayısı, sınıf

3 değişkenlerinin sayısı, ortalama iç içe geçmiş derinlik (average nested depth), ortalama çevrimsel karmaşıklık, ortalama mimari karmaşıklık metriklerini de sınıf bazında hesaplayabilmektedir. CK metrikleri aşağıda açıklanmaktadır: 1. WMC (Weighted Method per Class): WCM, bir sınıftaki metot sayısıdır. McCabe IQ aracı içerisinde, eşik seviyesi 14 olarak gösterilmiştir. 2. DIT (Depth of Inheritance Tree): DIT, bir sınıftan kalıtım ağacındaki kök elemana olan en uzak yolun mesafesidir. McCabe IQ aracı içerisinde, eşik seviyesi 7 olarak gösterilmiştir. 3. RFC (Response for a Class): Bir sınıf içerisinde yer alan metot sayısı ile kalıtımdan gelen metot sayısı toplanarak hesaplanır. McCabe IQ aracı içerisinde, eşik seviyesi 100 olarak gösterilmiştir. 4. NOC (Number of Children): Sınıfın çocuklarının sayısı ya da bir sınıftan türeyen sınıfların sayısı olarak tanımlanabilir. McCabe IQ aracı içerisinde, eşik seviyesi 3 olarak gösterilmiştir. 5. CBO (Coupling between Object Classes): A sınıfı B sınıfının özelliklerini (attribute) veya operasyonlarını kullanıyorsa, A sınıfının B sınıfına bağlı (coupled) olduğu söylenir. CBO, bir sınıfın kalıtım dışında bağlı olduğu farklı sınıfların sayısıdır. McCabe IQ aracı içerisinde, eşik seviyesi 2 olarak gösterilmiştir. 6. LCOM (Lack of Cohesion in Methods): Her özellik (attribute) için o özelliği kullanan metotların yüzdesi belirlenip ortalaması alınır ve bu değer 100 den çıkarılır. Elde edilen değer, LCOM değeridir. Sınıf içi kohezyon yüksek olması gerekirken, sınıflar arası bağlılık (coupling) düşük olmalıdır. McCabe IQ aracında, eşik seviyesi 75 olarak gösterilmiştir. 7. Ortalama mimari karmaşıklık: Bir modülün, sistemin diğer elemanları ile olan etkileşiminin karmaşıklığını ifade eder (fonksiyon çağırma sayısı). Bir modülde çağrılan fonksiyon sayısı toplanarak hesaplanır. Mimari karmaşıklık değerleri birçok faktöre bağımlıdır ve spesifik bir rakam vermek güçtür. Genel olarak 60 ı geçen modüllerin incelenmesi gerekir. Ortalama mimari karmaşıklık ise o sınıf içerisindeki metotların mimari karmaşıklığının ortalamasıdır [6]. 8. Ortalama çevrimsel karmaşıklık (CC): Modülün karar yapısının karmaşıklığını gösterir. 30 dan küçük değerler kabul edilebilir. Üç basamaktan oluşan CC değerleri, o modülün bakım yapılabilirliğinin çok düşük olduğunu ve kesinlikle kusur eğilimli olduğunu gösterir. Ortalama çevrimsel karmaşıklık ise o sınıf içerisindeki metotların çevrimsel karmaşıklığının ortalamasıdır [6]. 9. Public metot sayısı: Sınıf içerisindeki public metotların sayısıdır. 10. Sınıf değişkenleri: Sınıf içerisindeki veri elemanlarının sayısıdır. 11. Ortalama iç içe geçmiş derinlik (average nesting depth): Bir sınıf içerisindeki metotların iç içe geçmiş derinliklerinin ortalamasıdır. Örneğin; 2 tane iç içe for döngüsünün en içinde bir if kontrolü mevcutsa, böyle bir metotun iç içe geçmiş derinliği 3 dür. Bu çalışmada sadece metot seviyesindeki metrikler kullanılmıştır. 6 CK metriğini karmaşıklık açısından ele alırsak 3 gruba ayırmak mümkündür. Bu gruplar aşağıda verilmektedir: Kalıtım Karmaşıklığı (inheritance complexity): DIT ve NOC Bağlılık Karmaşıklığı (coupling complexity): RFC ve CBO Sınıf İç Karmaşıklığı (class internal complexity): WMC ve LCOM 2.2. Metot Seviyesindeki Metrikler Predictive aracı içinde hesaplanabilen metot seviyesindeki metrikler ve eşik seviyeleri aşağıda verilmektedir [6]: 1. Toplam kod satır sayısı: Kod satırlarının sayısıdır. Boş ve yorum satırlarını da içermektedir. Süslü parantez (brace) içerisindeki tüm satırlar sayılarak hesaplanır. Bu metrik, yürütülebilir olmayan satırları da içerdiğinden karmaşıklığı belirlemede kullanılması pek mümkün değildir. Tavsiye edilen değeri modülün yapısına bağlıdır. 2. Yorum satırı sayısı: Yorum satırlarının sayısıdır. Tavsiye edilen değer, modülün karmaşıklığına ve büyüklüğüne göre değişmektedir. 3. Çevrimsel karmaşıklık: Modülün karar yapısının karmaşıklığını gösterir. 30 dan küçük değerler kabul edilebilir arasındaki değerler modülün tehlikeli olduğunu gösterir ancak uzman görüşünün de alınarak karar verilmesi gerekir. Bunun sebebi algoritmaların bazen gerçekten karmaşık olabilmesidir. 3 basamaktan oluşan CC değerleri, o modülün bakım yapılabilirliğinin çok düşük olduğunu ve kesinlikle kusur eğilimli olduğunu gösterir.

4 4. Maksimum iç içe geçmiş derinlik (nesting depth): İç içe ifadelerin sayısıdır. Örneğin; iç içe 2 tane for döngüsü ve en içte bir if varsa, bu metotun maksimum iç içe geçmiş derinliği 3 olacaktır. 5. Döngü sayısı (loop): Metot içindeki döngülerin toplam sayısıdır. 6. Eşsiz (unique) operatör sayısı: Operatörlerin sayısıdır arası bir değer bu metrik için oldukça standarttır. Bu değer, 60 ın üzerine çıkınca modül karmaşıklaşmaya başlar. 125 in üzerindeki değerlerde modülün gözden geçirilmesi gerekir. 7. Eşsiz (unique) operand sayısı: arasındaki değerler oldukça standarttır. 60 dan yüksek değerler karmaşık bir modülü gösterirken, 100 den büyük değerler aşırı karmaşık modülleri gösterir. 8. Toplam operatör sayısı: Metottaki operatörlerin toplam sayısıdır. Operatörler dile bağlı olarak tanımlanır ancak aritmetik işlemler, bitwise işlemler, mantıksal işlemler ve operandlar üzerinde işleme neden olan özel anahtar sözcükler (return, sizeof, if) ve fonksiyon çağrıları birer operatör olarak kabul edilir arasındaki değer oldukça standarttır. 150 den büyük değerler karmaşıklığı gösterirken, 200 den büyük değere sahip olan modüllerin farklı modüllere ayrıştırılması gerekir. 9. Toplam operand sayısı: arası oldukça standarttır. 100 den büyük değerlere sahip olan modüllerin karmaşık olduğu bilinmektedir. 10. Mimari karmaşıklık: Bir modülün sistemin diğer elemanları ile olan etkileşiminin karmaşıklığını ifade eder (fonksiyon çağırma sayısı). Bir modülde çağrılan fonksiyon sayısı toplanarak hesaplanır. Mimari karmaşıklık değerleri birçok faktöre bağımlıdır ve spesifik bir rakam vermek güçtür. Genel olarak 60 ı geçen modüllerin incelenmesi gerekir. 11. Yürütülebilir (executable) ifade sayısı: Yürütülebilir satırların sayısıdır. 12. Yorum satırının kod satırına oranı: Yorum satırı sayısının kod satırı sayısına oranıdır. 0,05 den düşük değerler yetersiz yorum satırı olarak ifade edilir. 0,15 den büyük değerler uygundur. En azından 0,15 olan bir değer tavsiye edilir. Çok fazla yorum satırının olması da az olması gibi eleştirilmektedir, okumayı zorlaştırır. 13. Şartların (conditional) sayısı: Şartların sayısıdır. 14. Kararların (decision) sayısı: Kararların sayısıdır. 15. Yapısal (structural) karmaşıklık: Modül içerisinde yer alan karmaşık anahtar sözcüklerinin sayısına bağlı olarak kod karmaşıklığının ortaya konulduğu bir metriktir. Karmaşık anahtar sözcük (keyword), bazı kod satırlarını atlamamıza neden olan sözcüktür. 5 i geçen modüllerin önemli sayıda jump içerdiği ve okunmasının/anlaşılmasının zor olduğunu ifade edilir. 20 nin üzerindeki değerler okunması çok zor modülleri gösterir ve tasarım hataları genellikle bu modüllerde mevcuttur. 16. Çıkışların (exit) sayısı: Standart yazılım mühendisliği iyi yazılmış kodların tek giriş / tek çıkış olmasını önerir ve birden fazla return ifadesi kötü kodlama uygulaması olarak ifade edilir. Bu değerin 5 den fazla olması modülün gözden geçirilmesi gerektiğini ortaya koyar ve 20 den fazla olması bakım yapılabilirliğin çok zor olduğunu ve hata eğilimli olduğunu ifade eder. 17. Halstead Kelime (vocabulary): Bir modülü tamamen tanımlamak için gerekli olan eşsiz sözcüklerin (words) sayısıdır. Eşsiz operatör ve eşsiz operandların sayısı toplanarak hesaplanır arasındaki değerler oldukça standarttır. 100 den büyük değerler karmaşıklığı gösterirken, 125 den büyük değerler modülün parçalara ayrılması gerektiğini ortaya koyar. 18. Halstead Uzunluk (length): Bir modülü tamamen tanımlamak için gerekli olan sözcüklerin (words) toplam sayısıdır. Toplam operatör sayısı ve toplam operand sayısı toplanarak hesaplanır. 200 civarı oldukça standarttır ve 300 e kadar olması kabul edilebilirdir. 300 den fazla olanlar uzun modül olup, 500 den fazla olanlar ise kötü tasarlanmış ve kötü gerçeklenmiş modüllerdir. 19. Halstead Zorluk (difficulty): Bir modülün zorluğunu veya hata eğilimini gösterir. Aynı operandların aşırı kullanılmasına bağlı olarak hatayı ortaya koyan bir metriktir. Tek bir operand fazla sayıda kullanılmışsa ve hatalı atama yapıldıysa, birçok yerde hataya neden olacaktır. (Eşsiz operatör sayısı / 2)*(toplam operand sayısı/eşsiz operand sayısı) formülü ile hesaplanır. 35 e kadar olan değerler normaldir. 50 yi geçen değerler zorluğu ve hata eğilimini ortaya koymaktadır. 100 den büyük değerler karmaşıklığı ve hata eğiliminin şiddetini gösterir.

5 20. Halstead seviye (level): Zorluğun tersidir. 1 ve 0,02 arasındaki değerler oldukça tipiktir. 0,02 den küçük değerler hata eğilimli modülleri gösterir ve 0,01 den küçük değerler problemli modülleri işaret eder. 21. Halstead hacim (volume): Bir algoritmanın gerçekleme boyutunu tanımlar. 30 ve 1000 arasındaki değerler oldukça standarttır den büyük değerlere pek rastlanmaz den büyük modüllerin yeniden tasarlanması veya parçalara ayrılması gerekir. 22. Halstead zeka içeriği (intelligent content): Algoritmanın karmaşıklığının gösterimini sağlar ve teorik olarak programlama dili değişse de bu metrik aynı değere sahip olmalıdır. Hacim ve seviyenin çarpılması ile elde edilir. 50 den küçük değerler kabul edilir düzeydedir. 50 ve 100 arasındaki değerler modülün karmaşık olduğunu gösterir. 100 den büyük değere sahip metotların incelenmesi gerekir. 23. Halstead çaba (effort): Bir modülü gerçekleme veya anlama için gerekli çabadır. 100 den küçük değerler oldukça standarttır. 100 ve 500 arasındaki değerler düşük kaliteli kodu işaret eder. 500 den büyük değerler düşük kalitedeki kodu gösterir ancak tek başına bu metrik kullanılmamalıdır. 24. Halstead zaman (time): Modülü anlamak veya gerçeklemek için gerekli zamanı gösterir değeri programcının 1 saat zaman harcaması gerektiğini gösterir e kadar olan değerler kabul edilebilirdir den büyük değerler modülün düşük kalitede olduğunu tek başına göstermez, diğer metriklerle birlikte değerlendirilmelidir Halstead Metriklerinin Değerlendirilmesi Halstead, 1970 lerde önerdiği yazılım bilimi metriklerini (software science metrics), primitif ve türetilmiş metrikler olarak 2 gruba ayırmıştır. Programların operatör ve operandlardan oluştuğunu; operatör ve operand sayılarının program karmaşıklığı ile ilişkili olduğunu ifade etmiştir. Operatörler, derleyicinin derleme ya da çalışma zamanında bir eylem gerçekleştirmesine neden olur [7]. Diğer program sembolleri (token) ise operatörlerin ihtiyaç duyduğu operandlardır. Yorum (comment) satırları ne operand ne de operatördür. Halstead aşağıdaki metrikleri, primitif metrikler olarak açıklamıştır: µ 1 : eşsiz (unique) operator sayısı µ 2 : eşsiz (unique) operand sayısı N 1 : toplam operator sayısı N 2 : toplam operand sayısı Halstead, primitif metrikleri kullanarak yeni metrikler türetmiş ancak bu türetilmiş metrikler birçok açıdan eleştirilmiştir. İlk olarak; programın gerçekleme uzunluğu (implementation length of program) ve sözcük (vocabulary) metriklerine bakalım. Denklem 1 ve 2 ye göre, primitif metriklerin toplamlarının alındığı görülmektedir ve bu yeni metriklerin bu şekilde yeni bilgiler ortaya koyması mümkün değildir. N ile uzunluk gösterilirken µ ile sözcük metriği gösterilmektedir. N = N 1 + N 2 (1) µ = µ 1 + µ 2 (2) Bilgisayar bilimlerinde bir değerin 2 tabanına göre logaritmasının alınması gelenek haline geldiğinden, programın hesaplanmış uzunluğu (calculated length of program) ve programın hacmi (volume) metriklerinde de 2 tabanına göre logaritma uygulanmıştır [7]. Denklem 3 ve 4 te sırasıyla hesaplanmış uzunluk ve hacim metrikleri gösterilmektedir. Ñ = µ 1 log 2 µ 1 + µ 2 log 2 µ 2 (3) V = N log 2 µ (4) Temel Bileşen Analizi (Principal Component Analysis) gerçekleştirilirse, bu iki yeni metriğin primitif metriklerle aynı şekilde değiştiği, bu nedenle yeni bilgiler sunmadığı görülecektir. Bu noktada yeni metrikler türetmek üzere, 2 yeni kavram ortaya konulmuştur [7]: µ1*, gerçeklenen algoritma için farklı operatörlerin minimum sayısı µ2 *, gerçeklenen algoritma için farklı operandların minimum sayısı Bu yeni kavramlardan yeni metrikler türetilmek istenmesine rağmen, bu özelliklerin gerçek değerlerini ölçecek kurallar mevcut değildir. Bu nedenle, bu önerilen özellikler ölçümlere gürültü katmaktadırlar. Bu metrikler, yazılım metrik uzmanları tarafından yıllarca kullanılmış, ancak bu metriklerin geçerlenmesi yapılmamıştır [7]. Munson a göre [7], 4 primitif metrik yeterlidir. Yazılım kusur kestirim çalışmalarında bütün metrikleri kullanıp, daha sonra korelasyonun olduğu metrikleri özellik azaltma teknikleriyle yok etmek ve uygun alt metrik kümesini belirlemek mümkündür. Bu sayede, birbirleriyle korelasyon taşıyan metrikler veri kümesinden çıkartılarak model performansı iyileşecektir. Aşağıda bu özellikleri kullanan türetilmiş metrikler verilmektedir. 5. denklemle programın potansiyel

6 hacmi, 6. denklemle sınır hacmi hesaplanmaktadır. 7. denklemle program seviyesi, 8. denklemle program seviyesinin alternatif gösterimi hesaplanmaktadır. 9. denklemle bir programı gerçeklemenin zorluğu, 10. denklemle programın zeka içeriği, 11. denklemle program çabası, 12. denklemle programı yazmak için gerekli zaman, 13. denklemle programdaki tahmini hata sayısı hesaplanmaktadır. V* = (µ) (log 2 µ*) (5) V** = (2+ µ 2 *) ( log 2 (2+ µ 2 *) ) (6) L = V* / V (7) Ĺ = ( µ 1 *) (µ 2 ) / (µ 1 ) N 2 (8) D = 1 / L (9) I = Ĺ * V (10) E = V / L (11) T = E / 18 (12) B = E 2/3 / 3000 (13) 2.4. Önerilen Metrikler En son yapılan çalışmalarda [8], kusur kestirimi için metriklerden ziyade kullanılan algoritmaların daha önemli olduğu saptanmıştır. Uzun yıllar en iyi metrik kümesini bulmak üzerine çalışmalar sürdürmüş olan araştırmacıları düşündüğümüz zaman, bu sonuç oldukça ilgi çekicidir. Menzies ve arkadaşları [8], NASA açık veri kümeleri üzerinde yaptığı kusur kestirim çalışmasında, makine öğrenmesi tabanlı yaklaşımlardan en iyi performansın Naive Bayes algoritması ile alındığını raporlamışlardır. Algoritma uygulanmadan önce logfilter ile filtreleme yapılmaktadır. Literatürde çok farklı makine öğrenmesi algoritması bu amaçla kullanılmış ve iyi performans verdiği raporlanmıştır ancak bu çalışma en uygun algoritmayı raporlaması açısından önemlidir. Bu çalışmalarında, kusur kestirimi için metriklerden ziyade seçilen öğrenme algoritmasının daha kritik olduğunu da raporlamışlardır. Literatürdeki kusur kestirim çalışmalarında kullanılan metrikler dikkate alındığında aşağıdaki metriklerin, kusur eğilimliliği belirlemede minimum küme olarak kullanılması gerektiğini öneriyoruz. Ancak türetilmiş metrikleri hesaplayabilecek bir araç mevcutsa, o metrikleri de modellere katmak, dikkate almak mümkündür. Gerekirse özellik azaltma teknikleri ile birbiri ile korele olduğu belirlenen metrikler çıkarılabilir. Sınıf seviyesindeki metrikler olarak 6 adet CK metriği Metot seviyesindeki metrikler olarak; toplam kod satır sayısı, yorum satırı sayısı, çevrimsel karmaşıklık, eşsiz operatör sayısı, eşsiz operand sayısı, toplam operatör sayısı, toplam operand sayısı, yürütülebilir ifade sayısı Predictive aracı içerisinde türetilmiş Halstead metrikleri de hesaplanmakta ve bu metriklerin eşik seviyelerinin aşıldığı noktalarda modüller yüksek riskli ya da orta riskli olarak işaretlenmektedirler. Bu nedenle, bu çalışmada türetilmiş metrikler de dikkate alınmıştır. Kusur kestirimi konusunda uzun yıllardır çalışma yapan araştırmacılar, NASA açık veri kümelerindeki türetilmiş Halstead metriklerini kullanmamaktadırlar [9]. Ancak kusur etiketlerinin bilinmediği durumlar için kusur kestirim modellerinin kurgulanmasındaki zorluk dikkate alınırsa, türetilmiş metriklerin de eşik seviyelerine bağlı olarak değerlendirilme yapılması yararlı olacaktır. 3. SELinux Linux çekirdeğinin security dizini altında selinux klasörü yer almaktadır. Bu dizin altında yer alan 418 adet yöntem bu kapsamda incelenerek yüksek, orta ve düşük riskli yöntemler saptanmıştır. Bu analizleri sunmadan önce, selinux konusunda bilgi vermek yararlı olacaktır. Bu sayede, incelenen kodların önemi daha açık olarak ortaya konulabilir. SELinux, çeşitli güvenlik politikaları sunan bir Linux özelliğidir. Bu politikalardan birisi, Birleşik Devletlerin (U.S) Savunma Bakanlığı tipi zorunlu erişim denetimleri dir (mandatory access controls) ve Linux çekirdeği içindeki Linux güvenlik modüllerinin kullanımı ile bu politika gerçekleştirilebilir. SELinux, bir Linux dağıtımı değildir. Unix türü işletim sistemlerine (Linux veya BSD) uygulanabilecek değişiklikler kümesidir. SELinux de yer alan kavramlar, Birleşik Devletler Ulusal Güvenlik Teşkilatı (National Security Agency-NSA) tarafından gerçekleştirilen projelere dayanmaktadır [10]. SELinux yukarıda açıklandığı gibi, farklı güvenlik politikaları sunmakta, geleneksel Linux erişim denetim mekanizmasından önemli farklılıklar içermektedir. Denetimin fazla olması, performans açısından küçük sorunlar yaşatsa da, güvenliğin çok önemli olduğu sistemler için bu performans azalması ihmal edilebilir düzeydedir. Önceleri yama olarak Linux çekirdeğine ekleniyorken artık Linux ana hattına eklenmiştir. Bazı Linux dağıtımlarında bu özellik varsayılan (default) olarak seçili olarak gelebilmektedir. SELinux, ilk olarak Birleşik Devletler Ulusal Güvenlik Teşkilatı tarafından geliştirilmiş ve açık kaynak topluluğuna 22 Aralık 2000 de sunulmuş,

7 2.6.0-test çekirdeğine birleştirilerek 8 Ağustos 2003 de sürüm hazırlanmıştır. Önemli katkı sağlayanlar; Network Associates, Secure Computing Corporation, Trusted Computer Solutions ve Tresys isimli firmalardır. SELinux, Linux un 2.6.x sürümüne entegre edilmiştir ve ek yama kullanmaya gerek yoktur [10]. Güvenliği iyileştirilmiş Linux sayesinde, yeni çıkan güvenlik açıklıklarında (vulnerability) da sistemler sorun yaşamadan ayakta kalabilmektedir [11] yılında ortaya çıkan bazı güvenlik açıklıklarında, SELinux kullanan sistemler bir problemle karşılaşmamıştır [11]. SELinux u entegre eden Linux çekirdeği, zorunlu erişim denetimi politikalarının uygulanmasını zorunlu kılar, kullanıcı programlarını ve sistem sunucularının işlerini yapabilmeleri için minimum yetki ile sınırlandırır. Bu sayede, bu programların tampon taşması veya yanlış konfigürasyonlar nedeniyle zarar vermesini önler. Bu sınırlandırma mekanizması, geleneksel Linux erişim denetim mekanizmasından bağımsız çalışır. Değiştirilmemiş Linux sisteminde güvenlik, çekirdeğin doğruluğuna, hakka sahip uygulamaların doğruluğuna ve konfigürasyonların doğruluğuna bağlıdır. Bu alanlardan herhangi birinde problem olması tüm sistemin tehlikeye atılmasına izin verir. Bunun tam tersi olarak, selinux içerisinde güvenlik, çekirdeğin ve güvenlik politikası konfigürasyonunun doğruluğuna bağlıdır [10]. 4. Durum Çalışması Linux çekirdeğinin sürümü üzerinde, Predictive aracı çalıştırılarak yüksek riskli modüller belirlenmiştir. İncelenen metriklerin eşik seviyelerinin aşıldığı durumlarda, ilgili modül kırmızı ile işaretlenerek ilgili modülün yüksek riskli olduğu gösterilmiştir. SELinux kaynak kodları, \linux \security\selinux şeklinde linux kaynak kodlarının güvenlik dizini altında yer almaktadır. Bu dizinde yer alan kaynak kodlar, Şekil 1 de gösterilmektedir. Bu dizin içerisinde, yüksek riskli olduğu belirlenen metotlar Tablo 1 de gösterilmektedir. Bu metotların hangi metriklere bağlı olarak yüksek /orta riskli olarak işaretlendiği takip eden şekillerde gösterilmektedir. Şekillerde yeşil ile gösterilen modüller düşük riskli, sarı ile gösterilenler orta riskli, kırmızı ile gösterilenler yüksek risklidir. Metriklerin eşik seviyelerinin aşılma derecesi de bu renklendirme ile gösterilmektedir. Bu renkler, Predictive aracının varsayılan renk değerleridir. SELinux dizini içerisinde, include ve ss alt dizinleri yer almaktadır. Ayrıca, Şekil 1 de görüldüğü gibi bazı dosyalar bu alt dizinlerin içinde yer almayıp doğrudan SELinux dizini içerisinde bulunmaktadır. Şekil 1: SElinux Dizini İçerisindeki Dosyalar Tablo 1:SElinux Dizinindeki Yüksek Riskli Metotlar Metot Adı Dosya Adı mls_context_isvalid mls.c constraint_expr_eval services.c policydb_context_isvalid policydb.c class_read policydb.c policydb_read policydb.c cond_evaluate_expr conditional.c try_context_mount hooks.c socket_type_to_security_class hooks.c inode_mode_to_security_class hooks.c ss alt dizini içerisinde yer alan yüksek ve orta riskli dosyalar Şekil 2 de gösterilmektedir. mls.c, services.c, policydb.c, conditional.c ve hooks.c dosyaları içerisinde yer alan yüksek ve orta riskli metotlar takip eden şekillerde metrikleri ile birlikte gösterilmektedir. Düşük riskli metotlar ve eşik değerinin altında kalan metrikler (yeşille işaretleniyor) bu şekillerde gösterilmemektedir. SELinux dizini içerisinde; satır kod mevcut olup 418 metot bulunmaktadır. Bu metotlardan Tablo 1 de verilen 9 adet metot, yüksek riskli olduğundan metotların %2 sinin yaklaşık olarak yüksek riskli olduğu ifade edilebilir. SELinux dizininin ortalama çevrimsel karmaşıklığı, 5.47 olup, bu oldukça iyi bir değerdir. Ortalama mimari karmaşıklık ise 2.66 olarak hesaplanmıştır ve kabul edilir düzeyin altındadır. SELinux dizini altında 40 adet dosya mevcuttur. SELinux dizini içerisindeki, 20 adet modül ise orta risk düzeyindedir. Tüm metotlara oranı hesaplanınca,

8 metotların %5 inin orta düzeyde riskli olduğu ifade edilebilir. 389 metot ise tüm metrikler açısından eşik seviyelerinin altında olduğu için metotların %93 ünün düşük riskte olduğu söylenebilir. Kusur kestirim çalışmalarında şimdiye kadar elde edilen verilere göre, tüm modüllerde kusur çıkaran modüllerin en fazla %20 düzeylerinde olduğu saptanmıştır. NASA daki bazı projelerde kusurlu modül yüzdesi %7 olarak saptanmıştır (PC1 projesi). PC1 projesi, NASA da gerçekleştirilen uçuş yazılımıdır. Projenin detay bilgisi NASA tarafından verilmemektedir. Bu analizdeki verilere göre, yüksek ve orta riskli metotların kusur çıkaracağı düşünülürse kusurlu modül yüzdesi %2 + %5 = %7 olacaktır. 9 yüksek riskli ve 20 orta riskli modüllerin yüzdesi, tüm projenin %7 si düzeyindedir. Bu kestirim değeri, literatürde elde edilmiş değerlerle de uyumludur. Ancak net olarak hangi modüllerde kusur çıktığı bilinmeden bu çıkarımı doğrulamak mümkün değildir. SELinux projesi NSA ve diğer organizasyonların koordinasyonunda gerçekleştirilmiş olduğundan, test aşamalarında saptanan kusur verilerine ulaşmak pek mümkün görünmemektedir. Bu açıdan gerçekten bu metotların kusur çıkarıp çıkarmadığını söylemek zordur. İncelenen metotlar içerisinde en fazla yeniden yapılandırmaya (refactoring) ihtiyaç duyulan metotun, policydb.c içerisindeki policydb_read metotu olduğu söylenebilir. Bu metotun çevrimsel karmaşıklığı 101 dir. Yazılım Mühendisliği Enstitüsü ne göre [12], çevrimsel karmaşıklığı 50 den büyük olan metotlar yüksek riskli olup, test edilemez program kategorisine girmektedir. Tüm bağımsız yolların test edildiği durumda, tabii ki bu modüller de test edilebilir olmaktadır ancak bu tür metotların sayısının çok fazla olduğu modülleri ve aralarındaki etkileşimini düşünürsek, çevrimsel karmaşıklığı 50 den büyük olan modüllere test edilemez program denilmesinin nedeni daha kolay anlaşılabilir. policydb_read metotu; çevrimsel karmaşıklık, döngü sayısı, eşsiz operatör sayısı, toplam operand sayısı, toplam operatör sayısı, mimari karmaşıklık, yapısal karmaşıklık, Halstead hacim, Halstead sözcük, Halstead uzunluk metriklerinin eşik seviyelerini aşan değerlere sahiptir. Bu nedenle, bu metotun yeniden yapılandırılması ve/veya daha fazla test edilmesi gerekmektedir. Aksi halde, bu metotun bakım yapılabilirliğinden söz etmek güçleşir ve yeni özellikler eklerken kusurlara neden olunabilir. Yüksek riskli metotların metrikleri incelendiğinde; 6 yüksek riskli metotun çıkış (exits) metriği nedeniyle, 2 yüksek riskli metotun yapısal karmaşıklık (structural complexity) metriği nedeniyle ve 1 yüksek riskli metotun (policydb_read) yukarıda açıklanan birçok metrik nedeniyle yüksek riskli olduğu saptanmıştır. Metotlardaki return ifadelerinin sayılması ile çıkış metriği hesaplanmaktadır. Bu ifadelerin sayısının 6 metot için eşik seviyesinin üstünde olduğu saptanmıştır ancak diğer metrikler bu metotlar için uygun değerdedir. Karmaşık anahtar sözcük (keyword), bazı kod satırlarını atlamamıza neden olan sözcüktür ve bu sözcükler, yapısal karmaşıklığı hesaplarken sayılmaktadır. 2 metot için bu metriğin eşik seviyesinin üzerinde olduğu ve bu metotların yüksek riskli olduğu saptanmıştır. 5. Sonuç ve Gelecek Çalışmalar Bu çalışmada, uygulayıcıların kullanabilecekleri metot ve sınıf seviyesindeki metrikler açıklanmıştır. Ticari bir araç kullanılarak, SELinux projesi içerisindeki kaynak kodların risk durumu analiz edilmiştir. Kullanılan eşik seviyeleri ISM firmasının NASA nın verilerini yıllardır inceleyerek elde etmiş olduğu eşik seviyeleridir. Predictive aracı içerisinde eşik seviyelerini değiştirmek mümkündür. Bu çalışmada, yüksek riskli modüllerin kusur kestirim modelleri geliştirilmeden de sadece metrik ve eşik seviyelerine bağlı olarak belirlenebileceği örnek bir senaryoda gösterilmiştir. Yazılım geliştirme aktiviteleri süresince bu metriklerin hesaplanması ve yüksek risk doğuracak modüllerin yeniden yapılandırılmaya tabi tutulması gerekmektedir. Yeniden yapılandırmanın mümkün olmadığı durumlarda, bu modüllerin daha fazla test edilmesi kaçınılmazdır. Bu yıl itibariyle yazılım metriklerinin en popüler yazılım geliştirme ortamlarına (Visual Studio vb.) girdiği de dikkate alınırsa, önümüzdeki yıllarda yazılım geliştiricilerin yazılım metriklerine daha fazla önem vereceğini söylemek mümkündür. Tümleşik geliştirme ortamları içerisinde bu metriklerin hesaplanıyor olması, geliştiricilerin bu metrikleri daha fazla benimsemesini sağlayacak, bu metriklere bağlı olarak yazılım geliştirme prensipleri şekillenecektir. Kusur açısından yüksek riskli modülleri belirlemeye yarayan bu araçlar sayesinde, yazılım geliştirme ve yazılım kalitesi konusunda çok fazla bilgi sahibi olmayan son kullanıcılar ya da proje paydaşları, projede üretilen kaynak kodların kalitesini kolaylıkla görebilecektir. Kod kalitesini sağlamaya yönelik metriklerin kullanıldığı bu tür çalışmalar sayesinde, daha kaliteli ve bakım yapılabilirliği daha yüksek yazılımların ortaya çıkması beklenmektedir. Önümüzdeki dönemde, geliştireceğimiz Eclipse tabanlı araç içerisinde, önerdiğimiz metrikleri kullanmayı hedeflemekteyiz. Bu metrikleri öncelikli olarak, eğiticili öğrenme algoritmaları ile birlikte kullanacak

9 sonrasında yarı-eğiticili modellerin geliştirilmesi için de bu metriklerden yararlanacağız. Çoğu yazılım geliştirme aracı, yeniden yapılandırma için bizlere birçok yetenek sunmaktadır. Bir projedeki bir metotun adının değiştirilmesi, sınıfın ikiye bölünmesi gibi işlemler kolaylıkla bu tür araçlarla gerçekleştirilebilmektedir. Ancak bu araçların hemen hemen hiçbirinde yeniden yapılandırmada hangi modüllerin ele alınması gerektiği önerilmemektedir. Binlerce kaynak kod dosyası ve yüz binlerce metotun olduğu durumda, yeniden yapılandırmaya hangi modülden başlanacağı büyük bir sorundur. Bu noktada bu çalışmada açıklanan türde araçlarla yüksek riskli olduğu belirlenen modüller saptanarak bu modüller üzerinde yeniden yapılandırma işlemlerine başlanabilir. Kalite güvence grupları, yazılım geliştiricilerin kodları ve içerikleri hakkında bilgi sahibi olmadan da bu tür araçlarla yüksek riskli modülleri saptayabilmekte ve geliştiricilerden bu kapsamda bilgi isteyebilmektedir. Proje hakkında hiç bir bilginiz olmadan, bu tür kestirimleri yapıyor olmak aslında yazılım mühendisliği açısından önemli bir kazanımdır. Büyük yazılım projelerinde gözden kaçan noktaları ya da ileriki dönemde bakım yapılabilirlik açısından ciddi sorunlar yaşanabilecek modülleri erken safhada bu sayede belirleyebilirsiniz. İlgiye yönelik (aspectoriented) programlama yaklaşımının, her kavramı ilgi olarak değerlendirdiği simetrik durumlar için özel ilgi metriklerinin belirlenmesi ve bu kapsamda modellerin kurulması gelecekte gerçekleştirilebilecek çalışmalar olarak değerlendirilebilir. Literatürde ilgiye yönelik metriklerle, kusur eğilimli ilgilerin kestirildiği bir çalışmaya rastlanmamıştır. 7. Kaynaklar [1] McCabe, T., (1976), A complexity Measure, IEEE Trans. on Software Eng., 2(4): [2] Halstead, M., (1977), Elements of Software Science, Elsevier North-Holland, New York. [3] Gilb, T., (1976), Software Metrics, Chartwell-Bratt. [4] Çatal, Ç., Diri, B., (2007), Software Fault Prediction with Object-Oriented Metrics Based Artificial Immune Recognition System, Lecture Notes in Computer Science 4589, Springer-Verlag, sf [5] Çatal, Ç., Diri, B., (2008), A Fault Prediction Model with Limited Fault Data to Improve Test Process, Lecture Notes in Computer Science 5089, Springer- Verlag, sf [6] redictive/explanationofmetrics.pdf [7] Munson, J. C., (2003), Software Engineering Measurement, CRC Press Company, Boca Raton London, New York. [8] Menzies, T., Greenwald, J., ve Frank, A., (2007), Data Mining Static Code Attributes to Learn Defect Predictors, IEEE Transactions on Software Engineering, 33(1): [9] Seliya, N., Khoshgoftaar, T. M., (2007), Software Quality Estimation with Limited Fault Data: a Semi- Supervised Learning Perspective, Software Quality Journal, 15(3), [10] [11] [12] ww.sei.cmu.edu/str/descriptions/cyclomatic_body.html 6. Teşekkür Bu çalışma, 107E213 proje koduyla TÜBİTAK tarafından desteklenmektedir. Yayındaki hiçbir görüş, tespit ve kanaat TÜBİTAK ın resmi görüşü değildir. Projede gerçekleştirilecek olan Eclipse tabanlı ürün için bu çalışmada ifade edilen metriklerden yararlanılacaktır. Sınırlı sayıda ya da varolamayan kusur verisiyle kusur kestirimi modellerinin geliştirilmesi, bu proje kapsamında gerçekleştirilecektir.

10 Şekil 2: ss Alt Dizini İçerisindeki Yüksek/orta Riskli Dosyalar Şekil 3: mls.c Dosyası İçindeki Yüksek/orta Riskli Metotlar Şekil 4: services.c Dosyası İçindeki Yüksek/orta Riskli Metotlar Şekil 5: policydb.c İçerisindeki Yüksek/orta Riskli Metotlar

11 Şekil 6: conditional.c İçerisindeki Yüksek/orta Riskli Metotlar Şekil 7: sidtab.c İçerisindeki Yüksek/orta Riskli Metotlar Şekil 8: ebitmap.c İçerisindeki Yüksek/orta Riskli Metotlar Şekil 9: avc.c İçerisindeki Yüksek/orta Riskli Metotlar