Ana içeriğe atla

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

İlk makalemizde genel bir giriş yapmış ve kod metriklerinden bahsetmiştik. Kod Analizi aracı yönetilebilir assemblyleri analiz ederek, assemblyler hakkında bilgileri raporlayan bir araçtır. Microsoft .Net Framework Dizayn Kurallarına göre programlama ve dizayn kuralı ihlallerini gösterir. Analiz aracı, kontrol ettiği kurallara uymayan yerleri birer uyarı olarak gösterir. Uyarı mesajları, hangi kuralın ihlal edildiğine ve mümkünse problemin nasıl çözüleceğine dair bilgileri içerir.
Kod Analizi Özelliğinin Açılması
Solution Explorer’da bir proje seçilip projenin properties’ine girilerek, Code analysis tabına gidilebilir. Şekil 1’deki gibi Enable Code Analysis on Build (defines CODE_ANALYSIS constant) seçeneği işaretlenirse, şekilde gözüken kuralların hepsi kontrol edilecektir. İstenilen kural işareti kaldırılarak devre dışı bırakılabilir.
image
Şekil 1. Code Analysis Tab
Kod Metriklerinin Kod Analizine Entegre Edilmesi
Maintainability Index, Class Coupling, Depth of Inheritance ve Cyclomatic Complexity metrikleri, Visual Studio’nun kod analizinde kural olarak tanımlıdır. Bu kuralları açarak kod metriklerine uygun kod yazılabilmesi sağlanabilir. Bu kurallar şekil 1’de gösterildiği gibi Code Analysis tabındaki “Maintainability Rules” penceresi altında durmaktadır. Hangi kuralın hangi kod metriğine karşılık geldiği ve hangi koşullarda uyarı verecekleri ise Tablo 1’de gösterilmiştir.


Tablo1.
Kod Metrikleri ve Treshold Kuralları
Metric Corresponding Rule Threshold
Depth of Inheritance CA1501 AvoidExcessiveInheritance Warning at above 5 levels deep
Complexity CA1502 AvoidExcessiveComplexity Warning at above 25
Maintainability Index CA1505 AvoidUnmaintainableCode Warning at below 20
Class Coupling CA1506 AvoidExcessiveClassCoupling Warning at above 80 for class and above 30 for a method
Referanslar
Özlem KARAGEDİK

Yorumlar

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