Ana içeriğe atla

Visual Studio 2008’de Kod Metrikleri ve Kod Analizi (Static and Dynamic Code Analyze) – Bölüm 1

Statik kod analizi, uygulama çalıştırılmadan (derleme sırasında), kaynak kodlarının incelenmesi ve analiz edilmesi anlamına gelmektedir. Visual Studio Team System 2008, statik kod analizi yapabilmek için kendi araçlarına sahiptir. En temel amaç, kod analizi araçlarını kullanarak kaynak kodların standart programlama ve dizayn kurallarına uygunluğunun gözden geçirilmesidir. Kod analizleri, “Buil Automation & Continuous Integration (Set Otomasyonu ve Sürekli Tümleştirme)” sürecinde de önemli bir yerde bulunmaktadır. Biz bu yazımızda, sadece kod metrikleri olarak adlandırılan kurallara değineceğiz. Bir sonraki makalede ise Kod Analizi kısmına bakacağız.
Kod Metrikleri (Code Metrics)
Kod metrikleri, kaynak kodları incelemek ve çeşitli ölçülere göre yazılımı derecelendirmek için kullanılan matematiksel ve istatistiksel yöntemlerdir. Kod metrikleri ile geliştiriciler hangi tiplerin veya metotların yeniden ele alınması gerektiğini, düzenlenmesi gerektiğini anlayabilirler. Kod metrikleri kullanılarak, koddaki potansiyel sorunlar erkenden ortaya çıkartılmış ve problemli alanları yeniden düzenleyebilmek için yeterince zaman kazanılmış olur. Kod metrikleri ile sadece yazılımın sağlığı incelenmiş olmaz, kod metrikleri aynı zamanda koddaki bakımı mümkün olmayan ve karmaşık noktaların da görülmesini sağlar.

Visual Studio 2008 kod metrikleri, bir projenin sınıflarını, modüllerini ve namespacelerini, çeşitli ölçülerle değerlendirerek potansiyel sorun kaynaklarını vurgular. Visual Studio 2008, 5 kod metriği ile birlikte gelmektedir. Bu kod metrikleri;
  1. Class Coupling,
  2. Depth of Inheritance,
  3. Cyclomatic Complexity,
  4. Lines of Code
  5. Maintainability Index’tir.
Kod Metrikleri, Solution Explorer’da bir projeye veya solution üzerine sağ tıklayıp “Calculate Code Metrics” diyerek veya Analyze menüsünden “Calculate Code Metrics For Solution / Project” ile hesaplanabilir. Sonuçlar “Code Metric Results” penceresinde şekil 1’deki gibi gösterilecektir.
image
Şekil 1. Code Metric Results
1. Class Coupling
Bu metrik; sınıf seviyesinde, parametreler, yerel değişkenler, dönüş tipleri, method çağırımları, generic ilklemeler, base sınıflar, arayüz implementasyonları vb. aracılığıyla diğer sınıflarla olan bağlantı sayısını ölçer. Kısaca bu metrik bir sınıfın bağlı olduğu sınıf sayısını gösterir. Bu sayı hesaplanırken int32, object, string gibi primitive ve built-in tipler gözardı edilir. Bu sayının mümkün olduğunca az olması beklenir. Çünkü yüksek coupling değerleri, bir tasarımın diğer sınıflara bağımlılıkları yüzünden, yeniden kullanılmasının ve bakımının güç olduğu anlamına gelir.
Şekil 2’de coupling değerlerinin nasıl hesaplandığı gösterilmiştir. Buna göre Order Sınıfı, Currency ve Transaction olmak üzere iki sınıfla ilişkilidir. Product sınıfı sadece Supplier sınıfı ile ilişkilidir, ve coupling değeri 1’dir. Country sınıfı ise hiç bir sınıfa bağımlı değildir, bu yüzden coupling değeri 0’dır.
image
Şekil 2. Class Coupling örneği
2. Depth of Inheritance
Kalıtım derinliği, bir sınıfın, kalıtım ağacında o sınıfın üst düğümünden köke kadar olan sınıfların sayısını gösterir. Hiyerarşi ne kadar derinleşirse, hangi metodların veya alanların nerelerde tanımlandığını veya yeniden tanımlandığını takip etmek de zorlaşır. Çok derin kalıtım ağaçları, uygulamanın testinin ve bakımının karmaşıklığını arttırır. Örneğin bir sınıf direkt olarak Object’ten türemişse derinliği 1 olacaktır. Kalıtım derinliği hesaplanırken, interfaceler sayılmaz. Şekil 3 ‘de kalıtım derinliğinin hesaplanmasına örnek verilmiştir.
image
Şekil 3. Depth of Inheritance
3. Cyclomatic Complexity (CC)
Cyclomatic Complexity programdaki birbirinden farklı kod akışlarının sayısıdır. Daha basitçe açıklamak gerekirse, programdaki karar noktaları olan if bloklarının, do, while, foreach ve for döngülerinin ve switch case bloklarının sayısıdır. Yüksek cyclomatic completixy değerine sahip olan kodların test ve bakımı zor olmaktır. Çünkü bu kodlarda test edilebilecek çok sayıda farklı akış vardır.
Cyclomatic Complexity(CC) değerini hesaplamak için aşağıdaki gibi basit bir yol izlenebilir.
  1. Metodun akışına CC= 1 değeri ile başla.
  2. Her bir if,while,repeat, for, and , or anahtar kelimeleri veya eşdeğerleri için CC’ye 1 ekle
  3. Switch’teki her bir case için CC’ye 1 ekle
Tablo 1’deki kod örneğinin Cyclomatic Complexity’sini hesaplayacak olursak metoda CC=1 ile başlıyoruz. For döngüsü için 1 ekliyoruz(CC=2). If bloğu için 1 ekliyoruz(CC=3).
Tablo 1. CC Örneği
public void TestCyclomaticComplexity()        {
                int x = 5;
                for (int z = 0; z < 5; z++)
                    x = x + 1;
                if (x > 10 && x < 5) x = x - 3;
        }
Şekil 4’te ise metodlar için cyclomatic complexity değerleri ve riskleri belirtilmiştir. Cyclomatic complexity değeri ne kadar yüksekse metodun karmaşıklığı da o kadar fazladır.
image
Şekil 4. CC değerleri ve Riskleri
4. Lines Of Code (LOC)
Lines of Code, bir metoddaki işletilebilir kod satır sayısını gösterir. Alfabe dışı karakterler, commentler, tip ve namespace tanımları bu hesaplamanın dışında kalır. Çok yüksek bir değer, bir tipin veya metodun çok fazla iş yaptığı, bu yüzden de bölünmesi gerektiği anlamına gelir.
5. Maintainability Index
Sınıf üyeleri veya tipler seviyesinde kod bakımının kolaylığına gösteren bu değişken 0-100 arasında bir değer alır. Bu değerin yüksek olması programın sürdürebilirlik seviyesinin yüksek olduğu anlamına gelir. Namespace veya assembly seviyesindeki maintainability index, o namespace veya assembly içerisindeki bütün tiplerin maintainability indexlerinin ortalamasıdır. Bu metrik, Halstead Volume, Cyclomatic Complexity ve Lines of Code metrikleri bir araya getirilerek oluşturulmuştur. Halstead Volume, kullanılan işlenen (operand) ve işlemcilerin (operator) sayısıyla ilgili bir metriktir. Maintainability index için kullanılan denklem aşağıda verilmiştir.
Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)
Maintainability index, kolay bir gösterimi olması için ikonlarla ifade edilmiştir. İkonlar için, değer aralıkları ve sürdürebilirlik seviyeleri şekil 5’de verilmiştir.
image
Şekil 5. Maintainability Index
Özlem KARAGEDİK

Yorumlar

  1. Yıllar geçmesine rağmen hala güncelliğini koruyan çok güzel bir yazı. Teşekkürler.

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara