Sayfalar

Yazılım Ölçümleme

   Bir önceki yazımda nesne yönelimli yazılımda dizayn prensiplerini işlemiştim.Okurların bu yazıda bahsedilen metriklerin nereden kaynaklandığını daha iyi algılamaları açısından, dizayn prensiplerine göz atmalarını öneririm.

   Yazılım ölçümlemede kullanılan metrikleri temel olarak iki kategoriye ayırabiliriz :

  • Ürün Kalitesi ile ilgili metrikler
    • Kalite , büyüklük , modulerlik vb
  • Süreç maliyet/kaynak planlaması ile ilgili metrikler
    • Efor , zaman cetveli , kaynak gereksinimi
   Bu yazıda nesne yönelimli yazılımda kalite  ölçümlemede  kullanılabilecek metrikler üzerinde durulmuştur.Yazıda nesne yönelimli programlaya özel yöntemlerin yanı sıra geleneksel yöntemlerden ; nesne yönelimli programlamaya aktarılan yöntemler de ele alınmıştır. Nesne yönelimli yazılımlara her ne kadar bir kısım geleneksel ölçme yöntemleri kullanılabilse de genel olarak kullanılabilen metrikler geleneksel yöntemlerden oldukça farklıdır.
  Yapılan araştırmalarda yazılım süreçlerinde bakım maliyetlerinin , geliştirme maliyetlerinin neredeyse iki katı olduğu gözlenmiştir.Bu bize kaliteli yazılım üretmenin zorluğunu göstermektedir.



    Yazılımın kalitesinin garanti altına alınması ve  iyileşme sağlanabilmesi , sürekli ölçümleme ve iyileştirme ile olabilir.Gerekli iyileştirmeler ölçümleme sonucu elde edilen bilgilere dayanılarak yapılabilir.Ölçümleme yapılmadan hazırlanan eylem planları kesinlikle gerekçesiz ve gelişigüzel olacaktır.



Geleneksel Metrikler

 
   Bu bölümde ele alınan metrikler geleneksel metriklerden nesne yönelimli yazılıma uyarlanabilecek olanlardır.

Kod  Büyüklüğü (Lines Of Code LOC)

  
   Geleneksel olarak yazılımın boyutu satır sayısı ile  ölçülür. Satır büyüklüğü çeşitli şekillerde ölçülür :
  • Satır Sayısı  ( Lines Of Code – LOC ) ölçümü programın tüm satırlarının sayılmasıdır.
  •  Yorum ve boşluk içermeyen (Non-comment Non-blank NCNB veya Source Lines Of Code SLOC )  programın yorum satırları ve boş satırlardan arındırılmış halidir.
  • Çalıştırılabilir yordam sayısı (Executable Statements EXEC) program içinde yer alan yordam sayısıdır.

Örneğin aşağıdaki kod :
IF X = 3
// Comment Line
Then
Y = 10
4 LOC , 3 NBC  ve 1 EXEC olarak sayılır

   Satır büyüklüğü pek çok dile uyarlanabildiği için oldukça kullanışlı ve ölçümü beklenen bir metriktir.Ancak satır büyüklüğü üzerine yorum yapmak için dilin karmaşıklığı , projenin karmaşıklığı gibi faktörler de göz önünde bulundurulmalıdır.Yazılım istatistiklerini biriktiren şirketler yeni projelerin faktörlerini göz önüne alarak , kestirimlerde bulunabilirler.

   Satır büyüklüğünün küçük olması yazılım için hedef olmalıdır.

Yorum Oranı (Comment Percentage - CP)


   Yorum oranı (Comment Percentage CP) programın için hazırlanmış yorum satırlarının (kod ile birlikte ya da dışarıda) , toplam programın yorum ve boşluk içermeyen satır sayısına (SLOC) bölümü ile bulunur.Yüksek yorum oranı programların anlaşılabiliğini arttıran ve bakımını kolaylaştıran bir faktördür.

   Yorum oranının %20 ila %30 arası olması tavsiye edilen bir durumdur.

Döngüsel Karmaşıklık (Cyclomatic Complexity -CC)

  
   Thomas J. McCABE  tarafından ortaya konan bu metrik bir methodun içindeki algoritmanın karmaşıklığını ölçmek için kullanılır.Aynı zamanda bir methodun test edilmesi için gerekli test durumu sayısını da verir.

    CC = yollar  – düğümler + 2 

şeklinde hesaplanır.Örneğin bir IF cümlesi iki seçeneğe sahiptir.Eğer şart doğru ise birinci yol test edilmiş olur , hatalı ise ikinci yol test edilir.Aşağıdaki şekilde hesaplanış ile ilgili örnekler verilmiştir.



Methodların düşük karmaşıklığa sahip olması tercih edilir.Bu kodun anlaşılırlığının ve test edilmesinin kolay olduğunu gösterir. Döngüsel karmaşıklık , nesne yönelimli yazılımda kalıtım ilişkisi yüzünden bir sınıfın karmaşıklığını ölçmek için kullanılamaz.Fakat methodların karmaşıklığının toplamı , sınıfın karmaşıklığı olarak kabul edilebilir.Bir method için karmaşıklığın 10’u aşmaması tercih edilmelidir.Ancak 20’ye kadar kabul edilebilir.Bunu aşan değerler anlaşılması oldukça güç kodları gösterir.

 



Nesne Yönelimli Metrikler


Sınıf Temelli Metrikler


   Nesne yönelimli programlamada temel birim sınıftır.Bu bölümde yer alan metrikler sınıf temelli metriklerdir.Sınıf ve onun temel elemanları üzerinden alınan metrikler ile tüm ürün kalitesi hakkında genel fikirler verir.

Sınıf Method Sayısı (Number Of Methods per Class -NOM)


   Sınıf başına düşen method sayısı sınıfın karmaşıklığı açısından bir göstergedir.Aynı zamanda fazla method sayısı arabirimin ayrılması prensibine ( the interface segregation principle ) aykırı durumların da habercisidir.

( Ortalama method sayısı = Toplam Method Sayısı / Toplam sınıf sayısı  formulü ile  ortalam method sayısı elde edilir.)

   NOM değerinin 20 ‘nin altında kalması tercih edilmelidir. 40’dan küçük değerler de kabul edilebilir sınırlar içindedir.Ancak bu değerler sınıfların constructor ,  destructor ve ayrıca mutator (getxxx , setxxx gibi) methodlarının dahil edilmiş hali olarak kabul edilmelidir.Bu tip methodlar ayıklanmış haldeyken sınıfın method sayısının 10’u geçmemesi tercih edilmelidir.

Büyük NOM değerleri anlaşılması , yeniden kullanımı ve bakımı güç sınıflara işaret eder.

Chidamber ve  Kemerer Metrikleri

1.    Sınıf Başına Ağırlıklı Method  (Weighted Methods per Class -WMC)


    Döngüsel  karmaşıklık değerleri toplamının sınıf sayısına bölümü ile bulunur.WMC değerinin 100’ün altında olması tercih edilmelidir.WMC sınıf karmaşıklığı hakkında fikir veren en önemli donelerden biridir.Bu metriğin faydaları sınıf başına ortalama method sayısı gibi değerlendirilebilir.WMC değerinin 100’ün altında olması kabul edilebilir bir değerdir. WMC değeri NOM’dan farklı olarak sınıfın karmaşıklığı hakkında daha net bir fikir verir.

Bu metrik üzerinden genel olarak elde edilebilecek fikirler şu şekilde sıralanabilir :
  • WMC sınıfın karmaşıklığı hakkında fikir verir ve harcanacak geliştirme ve bakım eforları için gösterge sayılabilir
  • Büyük sayıda method içeren sınıfların üzerinde yapılacak değişiklikler , sınıftan türiyen sınıflar üzerinde potensiyel etkiye sahiptir
  • Daha fazla method içeren sınıflar daha uygulamaya özel ve yeniden kullanımı zor sınıflar olarak görülürler

Ekli grafikte örnek bir WMC dağılımı verilmiştir.Bu grafik yardımıyla projenin toplam karmaşıklığı hakkında fikir edinilebilir.WMC değeri 100’ün üzerindeki sınıfların yeniden ele alınması faydalı olacağından bu sınıf sayıları tablodan kolaylıkla seçilmektedir.

 


2.    Kalıtım Ağacının Derinliği (Depth of Inheritance Tree - DIT)

  
   DIT metriği sınıfın ebeveyn sınıflarının sayısını gösterir.Eğer çoklu kalıtım durumu söz konusu ise bu durumda hiyerarşideki en uzun yol kabul edilir.



  Örneğin yukarıdaki şekilde yer alan D sınıfı için DIT değeri 2 olarak kabul edilir.DIT bize kısaca kaç tane ana sınıfın potensiyel olarak sınıfımızı etkileyebileceğini gösterir.

  • Sınıf hiyerarşisinin derinliği arttıkça daha fazla method kalıtım alınır ve sınıfın davranışlarını öngörmek ; anlamak zorlaşır.
  •  Derin hiyerarşiler daha fazla method ve sınıf etkilendiğinden , dizaynı karmaşıklaştırır
  •  Ancak hiyerarşi derinleştikçe kalıtım alınan methodların yeniden kullanım potensiyeli artar

    DIT metriğine destekleyici olarak sınıfın kalıtım aldığı method sayısı (number of methods inhertied NMI) da ölçülebilir.
   DIT için önerilen rakam genellikle 5’in altında olmasıdır. 5’in üzerindeki derinlikler oldukça karmaşık yapılar doğurabilir.DIT’in 0 olması sınıfın kök  olduğunu gösterir.DIT’in ortalam 2-3 arası bir değerde olması yeniden kullanımın iyi seviyede olduğunu gösterir.2’den küçük derinlikler ise yeniden kullanımın zayıf olduğu alanları işaret eder.

Ekli grafikte örnek bir DIT dağılımı gösterilmiştir.


3.    Alt Sınıf Sayısı ( Number of Children - NOC)


   NOC metriği sınıftan türemiş alt sınıflarının sayısını verir.

·       Alt sınıf sayısı çoğaldıkça kalıtım özelliğine bağlı olarak yeniden kullanımın arttığı anlaşılır
·       Alt sınıf sayısının çokluğu  sınıfın hatalı soyutlama yapıldığını , belki de hatalı bir hiyerarşi kurulduğunu gösterebilir.
·       NOC sınıfın nüfus alanı hakkında bir fikir verir.NOC metriği yüksek sınıflar gözden geçirme , test gibi süreçlerin daha dikkatli ve uzun tutulması gereken yerlerdir.

DIT ve NOC metriklerinin kendi içinde getiri ve götürüleri vardır.Yüksek DIT değerleri artan karmaşıklığı gösterirken aynı zamanda artan yeniden kullanıma da işaret eder.Aynı şekilde yüksek NOC değeri artan yeniden kullanıma işaret ederken daha fazla test eforu harcanması gerektiğini gösterir.Ekli şekilde DIT ve NOC metriklerinin bir arada dağılımları gösterilmiştir.Bu tablodan bazı garip durumlar saptanabilir.Örnek şekilde ağacın üçüncü seviyesinde ancak 40 alt sınıfa sahip bir sınıf göze çarpmaktadır.

4.    Nesneler Arası Eşleme (Coupling Between Object Classes - CBO)


  CBO değeri sınıfın kalıtım ilişkisi dışında diğer sınıflar ile kurduğu bağımlılık (eşleme) sayısını gösterir.Örneğin diğer bir sınıfın methodlarının kullanılması ya da diğer sınıfın bir nitelik olarak tanımlanması vb. CBO değeri eşleme yapılmış sınıf sayısını gösterir.Örneğin bir A sınıfı methodları içerisinde diğer B sınıfına dört şekilde mesaj gönderiyor olsun.Bu durumda A ile B sınıfı arasında yalnız bir eşleme vardır.Eşleme sayısı gönderilen mesaj sayısı ile ilgili değil kaç farklı sınıf ile haberleşildiği ile ilgilidir.

·       Sınıflar arası çok sayıda eşlemenin bulunması moduler dizaynı zedeler ve yeniden kullanımı engeller.Bağımsız sınıfların başka uygulamalar içinden yeniden kullanımı daha kolaydır.
·       Modulariteyi ve kapsullemeyi düzenlemek için eşlemeler minimum düzeyde tutulmalıdır.Eşleme sayısının yüksek olması sınıfın değişikliklere karşı daha hassas ve bakımının daha zor olmasına yol açar.
·       CBO değeri dizaynın çeşitli kısımlarında uygulanacak testin ne kadar karmaşık olacağı hakkında bir fikir verir.Yüksek değerler daha zor testlerin yapılacağının göstergesidir.

CBO değeri sınıfın bağımsızlığının göstergesidir.CBO ve DIT değerleri 0 olan sınıflar tamamen bağımsız olarak çalıştırılabilir sınıflardır.

CBO değerinin 5’i aşmaması genellikle tavsiye edilmektedir.Ekli şekil örnek bir CBO grafiğini göstermektedir.






5.    Sınıf Yanıt Sayısı (Response for a Class - RFC)


     RFC sınıfın içindeki method sayısı + methodlar tarafından çağırılan method sayısının  (her method sadece 1 kez sayılmak üzere) toplamıdır. Formulü :
   RFC = |RS|
   RS = { M }È all i { Ri }
( { Ri } = I methodu tarafından çağırılan unique method sayısı ve { M } = sınıfın methodları )

şeklinde ifade edilebilir.RFC sınıf tarafından bir mesaja cevap için potensiyel olarak çalıştırılacak method sayısını verir.Buna sınıf hiyerarşisi içerisinde erişilebilecek tüm methodlar dahildir.Bu metrik sınıfın method sayısı ile diğer sınıflarla kurulan iletişim sayısının toplamı gibi görülebilir.

RFC metriğinin sınıf başına 100’den aşağı olaması kabul edilebilir bir durum olsa da 50’yi aşan bir sınıf genellikle pek görülmez.

  • RFC değerinin yüksek olduğu sınıfların anlaşılması daha zor olacağından  için test ve debug eforları daha fazla olacaktır
  • RFC değeri yükseldikçe sınıfın karmaşıklığı artar
  • RFC değeri ayrılacak test zamanının hesaplanmasına yardımcı olabilir

Aşağıdaki grafikte sınıflara göre RFC dağılımını göstermektedir.

 



RFC / NOM değerinin C++ için 5’i Java için 10’u aşmaması tavsiye edilmektedir.Ekli grafikte bu kurala uyan ve uymayan sınıflar gösterilmeye çalışılmıştır.

RFC > 5 x NOM

6.    Uyumsuzluk (Lack of Cohesion - LCOM)

 

  Uyumluluk nesne yönelimli programlamada oldukça önemli bir kavramdır.Bir sınıf elemanlarının birlikteliğinin derecesini gösterir.İyi bir dizayn yüksek uyumlulukta sınıflar sunmalıdır.

   Uyumluluk bir sınıfın birden fazla  soyutlama yapmamasını gerektirir.Aksi durumda sınıfın başka sınıflara bölünmesi gereklidir.

   Chidamber ve Kemerer’a göre sınıfın aynı değişkenlerine erişen birden fazla method varsa sınıfta bir uyumluluktan bahsedilebilir. LCOM bir sınıfın içindeki hiçbir ortak alanı paylaşmayan method toplamından , en az bir ortak alanı paylaşan method toplamının farkı ile bulunur.Bulunan değer 0’dan küçükse 0 kabul edilir.

C1 sınıfının M1, M2..., Mn şeklinde n tane methodu olsun . {Ii}   kümesinin Mi sınıfının  kullandığı sınıf değişkenleri olduğunu farzedelim .Bu şekilde her method için bir küme olduğunu fazedelim.
P değeri   kesişimleri boş olan kümelerin sayısı ( P = { (Ii,Ij) | Ii Ç Ij = Æ } )  ve  Q’yu kesişimleri boş olmıyan kümelerin sayısı ( Q = { (Ii,Ij) | Ii Ç Ij _ Æ }) olarak kabul edelim.Eğer tüm küme kesişimleri boş ise P değerini 0 kabul edelim.
Bu durumda LCOM = |P| - |Q| olarak kabul edilir.Eğer sonuç negatif ise LCOM = 0 olarak kabul edilir.

Örneğin M1 , M2 ve M3 methodları bulunan bir sınıfı ele alalım. M1’in kullandığı sınıf değişkenleri kümesi {I1} =  {a,b,c,d,e} , M2 methodunun kümesi  {I2} = {a,b,e} ve M3 methodunun kümesi  {I3} = {x,y,z}olsun . Bu durumda {I1} Ç {I2} kesişimi boş olmıyan , ancak  {I1} Ç {I3} ve {I2} Ç {I3} boş kümeler verir.Bu durumda 

P = 2
Q = 1
ve LCOM = P – Q    = 1  olarak bulunur.


·       Methodların uyumsuzsuzluğu sınıfın iyi kapsulleme (encapsulation) sunamadığının göstergesidir
·        Uyumsuzluğu yüksek sınıfların iki ya da daha fazla alt sınıfa bölünmeleri gözden geçirilmelidir
·       Methodlar arası farklılık , sınıf dizaylarındaki çatlakların bulunmasında yardımcı olur
·       Uyumsuzluk karmaşıklığı arttırır ve geliştirme sırasında hata yapılma ihtimalini arttırır

LCOM değeri sınıfın method sayısına bağlı olarak değişir.LCOM değerinin alabileceği sınır değer sınıfın method sayısıdır.Ekli grafikte sınıfların LCOM / NOM değerlerine göre dağılımı gösterilmiştir.
 
 

Paket Temelli Metrikler


   Nesne yönelimli programlamada bir başka temel birim de paket kavramıdır.Sınıflar boşlukta yaşan kavramlar değildir.Her sınıf belli bir pakete üye olmak zorundadır.Paket kavramı sayesinde sistemin temel yapı taşları belirlenebilir , sistem yapılandırılabilir.Sınıflar paketlere gelişi güzel atılamazlar.Paketlemede nesne yönelimli dizayn prensipler sıkı sıkıya uyulması gereklidir.Bu bölümde ele alınan metrikler paket dizaynının kalitesini ölçmeye yönelik olarak hazırlanan metriklerdir.

Kararsızlık (Instability)

  
   Durağanlık yazılımda , değişiklik sıklığı ile ilgili bir kavramdır.Bir paket ne kadar az değişiklik görüyorsa o kadar durağandır demektir.Durağanlığı sağlıyan unsurlar içeriğin karmaşıklığı , büyüklüğü , sağlam yapılmış olması vb. sebepler olabilir .Ancak nesne yönelimli dizayn içerisinde paketin durağan olmasını gerektiren en önemli unsur pakete olan bağımlılık sayısıdır. Bir başka deyişle pakete ne kadar bağımlılık var ise paket o kadar durağan olmalıdır.
   Kararsızlık bir paketin ne kadar kararsız ya da durağan olduğunu gösteren metriktir.Şu şekilde formulize edilebilir :

Ca = İç Eşleme ( Afferent Couplings )
Ce = Dış Eşleme ( Efferent Couplings )

I Kararsızlık  (Instability) .    I  =  Ce / (Ca + Ce) 

İç Eşleme ( Afferent Couplings - Ca)  bir paket içindeki sınıflara bağlı olan paketin dışındaki sınıf sayısıdır.


Dış Eşleme ( Efferent Couplings - Ce)  , bir paket dışındaki Class ’lara bağlı olan paketin içindeki Class sayısıdır.




    Karasızlık metriği 0 ile 1 arası bir değer alır. 0 tamamen durağan bir paketi (ya da sınıfın)  gösterirken değer 1’e doğru yaklaştıkça paketin kararsızlığı artıyor demektir.

Soyutluk (Abstractness)


   Bu metrik ölçümü yapılan paketin ne kadar soyut bir yapıda olduğunu gösterir. Durağan soyutluk prensibi ( Stable Abstractions Principle - SAP) ile yakından ilişkilidir. Bu prensip durağan olması gereken paketlerin soyut yapıda olmasını söyler.Şu şekilde formulüze edilebilir :

Nc Paket içindeki sınıf sayısı.(Soyut sınıflar da dahil)
Na Paket içindeki soyut sınıf sayısı  (arayüzler , soyut sınıflar vb)
A Soyutluk (Abstractness.) :   A = Na / Nc
  
   Bu metrik de kararsızlık metriği gibi 0 ile 1 arası bir değer alır .0 tamamen somut bir paketi gösterirken 1’e doğru yaklaştıkça paketin soyutluğu artıyor demektir.

Kararsızlık – Soyutluk Grafiği

     Durağan Soyutluk Prensibine  ( Stable Abstractions Principle - SAP) göre bir paket ne kadar durağan ise o kadar soyut olmalıdır.Paketin kararsızlık ve soyutluk değerleri üzerinden bir grafik oluşturulduğunda bu prensip görsel bir şekilde anlaşılabilmektedir.SAP prensibine göre eğer bir paket durağan ise (karasızlık 0 durumu) soyutluk o kadar artmalıdır. (soyutluk 1 durumu) .



      Üstteki grafikte SAP prensibine göre olması gereken ana çizgi görülmektedir.Ana çizginin dışında kalan bölgede bulunan paketler sıkıntılara yol açacaktır.

Uzaklık Metriği


   Bu metrik , kararsızlık-soyutluk grafiğinde bahsedilen ana çizgiye göre paketin  uzaklığı belirler.

D’ Normalize Uzaklık (Normalized Distance)  D’ = | A+I –1|
     Bu metriğin 0 çıkması paketin direk ana çizgi üzerinde olduğunu gösterir.1 çizgiden mümkün olan en büyük uzaklıktır.Metriğin değeri 0-1 arasıdır.

D Uzaklık  (Distance)   D =  |A + I – 1|
                                             ----------------
                                                    Ö2
   Bu metrik 0 - ~0,707 arası bir değer üretir.



Doğrusal Bağımlılık Prensibi Metriği (The Acyclic Dependency Principle Metric - ADP/ADPR)


   Doğrusal bağımlılık prensibi paketler arasındaki ilişki yapısında çevrimlerin bulunmaması yani döngüsel bağımlılıklar olmamasını gerektiğini söyler.


    Bu metrik genel olarak bakılan paket ve alt paketleri ile birlik ADP prensibine olan uyumu yüzde cinsinden gösterir.

Ndp  Paketler arası toplam Bağımlılık Sayısı (alt paketler dahil)
Ndac Paketler arası toplam doğrusal bağımlılık sayısı (alt paketler dahil)

ADP = (Ndac / Ndp ) * 100

ADP’ye tam uyumluluk önemlidir.Dolayısıyla bu metriğin %100 çıkması gereklidir.

Bağımlılığın Çevrimi Prensibi Metriği (The Dependency Inversion Principle Metric - DIP)


  Soyut eşleme (abstract coupling) olarak da adlandırılan bu prensip kısaca bileşenler arası eşlemelerin (ya da bağımlılıkların) somut sınıflar üzerinden değil soyut sınıflar üzerinden yapılması gerektiğini söyler.   DIP bir sınıf dizayn prensibi olduğu halde paket yapısı ölçümlemelerinin içinde de bir metrik olarak kullanılabilir.Bu metrik % cinsinden alınır.

  Nddp   Paket içindeki sınıflar arası toplam bağımlılık sayısı (alt paketler dahil)
  Nddac Paket içindeki somut sınıflardan soyut sınıflara toplam bağımlılık sayısı (alt paketler dahil)

  DIP  = (Nddac / Nddp ) * 100

Normal şartlarda bu metriğin vereceği değerlerin yorumu , bakış açısına göre değişir.Ancak genel beklenti uygulama özel paketlerde değerin düşük çıkması daha altyapıya yönelik paketlerde ise değerin yüksek çıkmasıdır. Değerin %100 çıkması tüm bağımlılıkların soyut sınıflara doğru kurulduğunu gösterir.


Kapsulleme Prensibi Metriği ( The Encapsulation Principle Metric  - EP)

  
  İyi kurulmuş moduler bir yapıda ve kapsulleme prensibine uygun yapılarda paket içeriğinin gerçekleştirme detayları dış dünyaya kapalıdır.Bu metriğin yorumu incelenen pakete bağlı olsa da paketin kalitesi hakkında bir fikir verebilir.Metriğin değeri paketin kapsullenme derecesinin yüzde cinsinden ifadesidir.

Ncc Pakette Dışarıya kapalı sınıf sayısı
Nc  Paketteki toplam sınıf sayısı

EP =  ( Ncc / Nc ) * 100

   Bu metrik paket kalitesi hakkında yorum yapmak için kullanılabilir ancak olması gereken değeri üzerinde bir tavsiye verilemez.Paketin yapısına göre yorum yapılmalıdır.

Sınırlı Boyut Prensibi Metriği ( The Limited Size Principle Metric LSP )


   LSP prensibine göre bir paketin içindeki alt paket ve üst seviye sınıf sayısı belli bir boyutu aşmamalıdır.

Nmx Proje için belirlenmiş paket sınırı sayısı (genellikle 10-15 arası)
Ncp      Paket içindeki alt paket ve üst seviye sınıf sayısı
LSP =  (Ncp    / Nmx )  *  100
   Bu metriğin değerinin % 100 çıkması sınır değerine ulaşıldığını gösterir.100’ün üzerindeki değerler paket için aşırı yüklemeyi ifade eder.

Kaynakça



  • McCabe, T.J., "A Complexity Measure", IEEE Transactions on Software Engineering, vol. SE-2, pp. 308-320, 1976.
  • Booch, G., Object Oriented Design with Applications, Redwood City, CA: Benjamin/Cummings, 1991.
  • Karl E. Wiegers  , “A Software Metrics Primer”  Software Development Magazine , July 1999
  • Dr. Linda H. Rosenberg , “Applying and Interpreting Object Oriented Metrics “ , Software Assurance Technology Center (SATC) at NASA
  • Software Quality Metrics for Object Oriented System Environments “ , Software Assurance Technology Center (SATC) at NASA , SATC-TR-95-1001
  • San Diego State University  “Metrics “  Lesson Notes
  • Edward V. Berard  , “Metrics for Object-Oriented Software Engineering “ , The Object Agency  Inc. Web Site
  • Edwin Hautus ,” Improving  Java Software Through  Package Structure Analysis “ , Compuware Europe


Hiç yorum yok:

Yorum Gönder