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

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ı 2

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 3

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. 4

Yazılım Kalitesi Buzdağı 5

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 6

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. 7

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... 8

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. 9

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) 10

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 11

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. 12

Bir Modül İçin En iyi Büyüklük? İ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). 13

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. 14

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 15

Bağımsız Yollar (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 16

strncat Örneği CC=5 17

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

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.

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

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 21

LDRA

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

JHawk Plug-ini 24

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

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

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. 27

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. 28

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. 29

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 30

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) 31

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. 32

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

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. 34

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 35

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 36

JHawk Plug-ini 37

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: 38

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

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.

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 41

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. 42

Ö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 ZOR DAHA KOLAY 43

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. 44

Maintability Index <=65 tehlike KLOC başına hata 2’den küçük olmalı Ö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... 45