YAZILIM KARMAŞIKLIĞININ ÖLÇÜLMESİ VE ENDÜSTRİ STANDARTLARIYLA KARŞILAŞTIRILMASI

1. YAZILIM KARMAŞIKLIĞININÖLÇÜLMESİ VE ENDÜSTRİ STANDARTLARIYLA KARŞILAŞTIRILMASI Yrd. Doç. Dr. Çağatay Çatal

2. Sunum Planı Yazılım Kalite Mühendisliği ve Yazılımda Ölçme Yapısal / Kavramsal / Hesaplamalı Karmaşıklık Büyüklük Çevrimsel Karmaşıklık Halstead Metrikleri Bilgi Akış Metrikleri Bakım Yapılabilirlik İndeksi Nesneye Yönelik Tasarım Metrikleri Endüstri Ortalamaları

3. Yazılımda Ölçme • YAZILIMDA ÖLÇME • Temel olarak 2 kural vardır: • Ölçümler yeniden üretilebilir olmalı (reproducible) • Metrikler problem için geçerli olmalı (valid) * Türetilmiş metrik oluştururken elma ile armut toplanmamalıdır! • unadjusted FP Hesabı • 4*i + 5*o + e*3 + 7*p + 10*f • i: # of external input types • o: # of external output types • e: # of inquiries • p: # of external files • f: # of internal files GOLD HILL

4. Yazılım Kalite Mühendisliği • Test, Kalite Güvence aktivetelerinden sadece birisidir. • Test dışında; fault tolerance, formal verification, inspection, fault prediction gibi farklı Kalite Güvence aktiveleri mevcuttur. • Yazılım Kalitesi artık, Mühendislik disiplini olarak ele alınmalıdır.

5. Yazılım Kalitesi Buzdağı

6. Basit Düşünme Üzerine... • “Basitlik zamanla kazanılan bir lezzettir. • İnsanoğlu içgüdüsel olarak yaşamı karmaşıklaştırır.” • Katharine Fullerton Gerould (1879-1944) • “Teknik yetenek karmaşıklığın üstatlığı iken yaratıcılık basitliğin üstatlığıdır” • Catastrophe Teorisi, 1977 • “Mümkün olduğu kadar basit ol, daha fazla değil” • Albert Einstein

7. Gereksiz Karmaşıklık • Gereksiz karmaşıklık, yazılım geliştirmenin “Tifolu Mary”sidir. • Gerçek adı Mary Mallone ’dur. İrlandalı bir göçmen, aşçı ve tifo hastası. 1869-1938 yılları arasında yaşamıştır, hayatı boyunca hiçbir hastalık belirtisi göstermeden 47 kişiye hastalık bulaştırmış, 3 kişinin ölümüne neden olmuştur.

8. Tifolu Mary... • Karmaşık bir tasarım (tifo) , kodlama, test, bakım aşamalarına kadar ilerleyecek ve sahada fazla hataya neden olup üretkenliği düşürecektir. • Tasarımı yapan için ölüme neden olmazken, programcı ya da test uzmanı için ölüm sebebi olabilir...

9. Hipotezimiz • Kod ne kadar karmaşıksa, • kodu anlamak o kadar zordur • Hata ayıklamak (debug), bakımını yapmak o kadar zordur • Bu da daha fazla hata ve düşük üretkenlik demektir.

10. Karmaşıklık Türleri • Yapısal Karmaşıklık(1. Structural) • Kavramsal Karmaşıklık(2. Conceptual) • Hesaplama açısından Karmaşıklık(3. Computational)

11. 1. Yapısal Karmaşıklık (Structural) • Yapısal karmaşıklık; tasarımın ve kodun kendi yapısı ile ilgilenir. • Tasarımda basitlik, modülerlik, gevşek bağlılık (loose coupling) ve sıkı kohezyon (tight cohesion) sağlar. • Kod içinde basitlik, basit kontrol akışları veya basit arayüzler gerektirir. Birçok yapısal karmaşıklık metrikleri mevcuttur. Büyüklük, çevrimsel karmaşıklık, halstead karmaşıklığı, bilgi akışı, sistem karmaşıklığı, nesneye yönelik yapısal metrikler

12. 1.1 Büyüklük (Size) • Empirik çalışmalara göre, sistem büyüklüğü (size) artsa bile hata yoğunluğu (defect density) sabit kalmaktadır. • Kod satır sayısı (KLOC) veya fonksiyon noktası (Function Point) bu kapsamda kullanılan metriklerdir. • İyi yazılımda hata, KLOC başına 2’den az olmalıdır. • Güvenli yazılımda hata, KLOC başına 1’den az olmalıdır.

13. İlk yapılan çalışmalarda büyüklükle hata yoğunluğu arasında rasgele bir ilişki olduğu düşünülmüş. (Hatton, 1997) ve (Denton, 2000) çalışmaları algoritmik bir ilişkiyi ortaya koymuş. En iyi nokta, hata yoğunluğunun en düşük olduğu noktadır (sweet spot). Tavsiye edilen 200 – 750 LOC Ya da kendi değerlerinizi modele ve verilerinize göre elde edin ! Programlama dili, Hata yoğunluğu için önemli bir faktör değildir (Denton, 2000). Bir Modül İçin En iyi Büyüklük?

14. 1.2 Çevrimsel Karmaşıklık (Cyclomatic) • Thomas McCabe tarafından 1976 yılında önerildi. • Bir program içerisindeki lineer bağımsız yolların sayısıdır • V(g)=e-n+2 • V(g)=bd+1, bd kontrol grafındaki ikili kararların sayısıdır. • CC ne kadar yüksekse, test ve bakım o kadar zordur.

15. McCabe CC • Rutin için 1 ile başla, if, while, for, repeat, and, or için 1 ekle • Switch’deki her case için 1 ekle CC=5

16. Bağımsız Yollar (Independent Paths) Independent Paths: 1, 8 1, 2, 3, 7b, 1, 8 1, 2, 4, 5, 7a, 7b, 1, 8 1, 2, 4, 6, 7a, 7b, 1, 8

17. strncat Örneği CC=5

18. SEI CC Seviyeleri www.sei.cmu.edu/str/descriptions/cyclomatic_body.html

19. CC Eşik Değeri Nedir? NASA’nın yaptığı çalışmalarda, CC’nin eşik değeri 20 olarak belirlenmiştir. CC > 50 ise alarm (kritik düzey) seviyesindedir. Hata eğilimli bir modüldür.

20. Hatayı Düzeltirken Hata Ekleme Olasılığı CC Bad Fix probability 1-10 5% 20-30 20% >50 40% 100e yaklaşırken 60%

21. CC Nerelerde İşe Yarar? • Kodun karmaşık kısımlarının belirlenerek detaylı incelemelerin nerede yapılacağının belirlenmesi • Karmaşık olmayan bölümlerin belirlenerek inceleme (inspection) gerekmeyen noktaların saptanması • Yeniden yapılandırma (refactoring) yapılacak noktaların saptanması • Daha fazla test edilecek modüllerin belirlenmesi

22. LDRA

23. .NET Refactoring Tool • http://www.xtreme-simplicity.net/

24. JHawk Plug-ini

25. Metrics Plug-in http://metrics.sourceforge.net/update

26. SourceMonitor C++, C#, JAVA, C, HTML, VB, Delphi, VB.net

27. 1.3 Halstead Metrikleri • 1977, Maurice Halstead. Bir programdaki operator ve operand sayısına bağlı olarak ölçümler • Operandlar; değişkenler (variable), sabitler (constant), string gibi değer alan token’lardır • Operatörler; bunların dışındaki herşey. Virgül, parantez, aritmetik operatörleri gibi.

28. 1.3 Halstead Yazılım Bilimi • n1: farklı operatorlerin sayısı • n2: farklı operandların sayısı • N1: toplam operator sayısı • N2: toplam operand sayısı • Not: Operatörlerin sayısının belirlenmesi açıkça verilmemiştir. • Bir tanıma göre; variables, constants ve stringsler operand’dır. Operatörler, diğer herşeydir.

29. 1.3 Halstead Diğer Metrikleri • Length N=N1+N2 • Vocabulary n=n1+n2 • Volume V=N(log2n) • Difficulty D =n1/2 * N2/n2 • Effort E=D*V • Kullanımda, Uygulanabilir değildir. Kod bittikten sonra ortaya çıkmaktadırlar. • Bakım çabası kestiriminde kullanılabilir ancak LOC daha basit bir metrik olarak karşımızdadır.

30. 1.4 Bilgi Akış (Information Flow) Metrikleri • Modüllere bilgi akışını ve çıkışını ölçer. • Yüksek seviyede bilgi akışı, karmaşıklığı gösterir. • Henry ve Kafura tarafından 1981’de önerildi. • IEEE 982.2 1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software, A25, Data of Information Flow Complexity, p. 112 • IFC=(fanin*fanout)2 • Ağırlıklı IFC = LOC * IFC

31. IEEE 982.2 • Fanin: local flows into a procedure + number of data structures from which the procedure retrieves data • Fanout: local flows from a procedure + number of data structures that the procedure updates • A B’yi çağırırsa, bu durum B’ye bir akış demektir (into B) • B bir değer döndürür ve A bu değeri kullanırsa, bu durum A’ye bir akış demektir (into A) • Başka bir prosedür, A’dan B’ye bir değer geçerse, bu durum B’ye akış demektir (into B)

32. Fan-in ve Fan-out Üzerine • Fan-in; hata eğilimliliği belirlemede yararlı değildir. Fan-out daha yararlıdır (Kitchenham, 1990). • Sıkça çağrılan rutinler, reusability’nin ve iyi tasarım tekniklerinin bir kanıtı olabilir. • Bu nedenle fan-in hesaplanırken; çağrılma sayısı kapsam dışı tutulup okunan veri yapıları sayısı yeterlidir.

33. Örnek Fanin: 3 Fanout:1 IFC: (3*1)2=9

34. 1.5 Sistem Karmaşıklığı Bakım Yapılabilirlik İndeksi (maintainability index) • 1990’larda bu indeks üzerine çok çalışma yapıldı. • LOC, Halstead metrikleri ve CC kullanıldı. • HP ve University of Idaho birlikte çalıştı. • 10 yılı aşkın süre geniş ölçekli askeri ve endüstriyel sistemlerde kullanıldı. • Amaç; bakım aşamasında, programcının kodun bakımını sağlarken bakım yapılabilirliği iyileştirdiğini veya bozduğunu görecek bir metrik oluşturmak.

35. MI-Maintainability Index MI= 171 - 5.2 * ln(aveV) - 0.23 * aveV(g') - 16.2 * ln (aveLOC) + 50 * sin (sqrt(2.4 * perCM)) • aveV = average Halstead Volume V per module • aveV(g') = average cyclomatic complexity per module • aveLOC = the average count of lines of code (LOC) per module • perCM = average percent of lines of comments per module

36. MI-Endüstri Değerleri (Coleman, 1994) Bakım yapılabilirlik MI Değeri Yüksek seviyede bakım yapılabilir >85 Orta düzeyde bakım yapılabilir >65 ve <=85 Bakım yapılabilirliği zor <=65

37. JHawk Plug-ini

38. 1.6 Nesneye Yönelik Tasarım Metrikleri • Chidamber-Kemerer metrikleri, 6 tane, popüler • OO metrikler hala evrimleşiyor. • Bazıları iyi tanımlanmamış, bazılarının elle sayılması güç. Ancak birçok araç piyasada mevcut. • Bu metriklerin yüksek değerleri beraberinde birçok problem getirmektedir:

39. Yüksek Değerli CK Metrikleri Yüksek CK metrikleri aşağıdaki değerlerle koreledir. • Düşük üretkenlik • Sınıfları yeniden kullanmada büyük çaba gereksinimi • Sınıfları tasarlamada büyük çaba gereksinimi • Sınıfları kodlamadaki büyük çaba gereksinimi • Bakım değişiklikleri sayısı • Hatalı sınıfların sayısı • Hatalar • Kullanıcı tarafından raporlanan problemler

40. Nesneye Yönelik CK Metrikleri • WMC (Weighted Method Count): Sınıftaki metot sayısı • DIT (Depth of Inheritance Tree): Sınıftan kalıtım ağacındaki kök elemana olan en uzak yolun mesafesidir. • RFC (Response for a Class):Bir sınıfın içerisindeki metot sayısı + Kalıtımdan gelen metot sayısı şeklinde hesaplanır. • NOC (Number of Children): Bir sınıftan türeyen sınıfların sayısı • CBO (Coupling Between Object Classes):A sınıfı B sınıfının özelliklerini veya operasyonlarını kullanıyorsa, A sınıfının B sınıfına bağlı 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. • 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.

41. CK Üzerine NASA Çalışmaları • 1999 yılında Rosenberg aşağıdaki 2 kriteri sağlayan modüllerin refactoring için işaretlenmesi gerektiğini ifade etmiştir. • RFC > 100 • CBO > 5 • RFC > 5 * sınıftaki metot sayısı • WMC > 100 • Metot sayısı > 40

42. 2. KAVRAMSAL KARMAŞIKLIK (Conceptual) • Anlamadaki zorluğu gösterir. • Maaş bordrosu uygulaması vs Real-time uygulama • Rekürsif kodların anlaşılması daha zordur. CC aynı olsa bile. • Kavramsal karmışıklığı ölçmek oldukça zordur. Henüz kavramsal karmaşıklığı ölçmek için bir metrik bulunmamaktadır.

43. Örnek Faktöriyel Rutin 1 int fact(int n){ if(n==0) return 1; else return n*fact(n-1); } Faktöriyel Rutin 2 int fact (int n) { total =1; for(int i=1; i<n;i++) total=i*total; return total; } DAHA ZORDAHA KOLAY

44. 3. HESAPLAMA KARMAŞIKLIĞI (Computational) Space ve time açısından hesaplama karmaşıklığı değerlendirilebilir. • Space açısından, rekürsif olan yapı (rutin 1) n+1 büyüklüğünde stack ihtiyacı vardır. • Space açısından rutin 2, boyutu 1 olan stack’e ve değişkenler için sınırlı bir alana ihtiyaç duyar. • Rutin 1, space açısından hesaplama karmaşıklığı büyüktür. • Time açısından, ikisi de n ile lineer artan bir şekilde hesaplama karmaşıklığına sahiptir.

45. ÖZET • CC >20 Tehlike • Önerilen LOC 200-750 • Maintability Index <=65 tehlike • KLOC başına hata 2’den küçük olmalı • RFC > 100 • CBO > 5 • RFC > 5 * sınıftaki metot sayısı • WMC > 100 • Metot sayısı > 40 • Ve TİFOLU MARY’DEN uzak duralim...