Nesneye Dayalı Yazılımlarda Yapısal Değişimlerin Analizi ve

Nesneye Dayalı Yazılımlarda Yapısal Değişimlerin Analizi ve

5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
Nesneye Dayalı Yazılımlarda Yapısal De÷iúimlerin Analizi ve
Maliyetlerinin Hesaplanması
Sinan Eski1
Feza Buzluca2
1
TÜBøTAK-BøLGEM, Kocaeli
Bilgisayar Mühendisli÷i Bölümü, østanbul Teknik Üniversitesi, østanbul
2
1
2
e-posta: [email protected]
e-posta: [email protected]
de÷iúimlerin yazılım mimarisini ve yapısını etkileme miktarını
hesaba katmak için de÷iúim türleri tanımlanmıú ve bunlara
a÷ırlıklar verilmiútir. Bu sayede, yorumlarda yapılan
düzenlemeler gibi yazılım mimarisini etkilemeyen “yapısal
olmayan de÷iúimler” hesaba katılmaz iken, yazılımın birçok
yerini etkileyebilecek bir de÷iúim olan metot imzasındaki
de÷iúimin etkisi daha ön plana çıkartılmıútır.
De÷iúim analizi yöntemi ile yazılımın ardıúıl sürümleri
incelenerek sınıflardaki de÷iúimler çıkarılmakta ve sınıfların
de÷iúim maliyetleri hesaplanmaktadır. Bu yöntem ile
yazılımın sürümleri arasındaki de÷iúim miktarı nicel olarak
ifade edilmektedir. Dolayısı ile bir sürümden di÷erine geçiúte
yapılan de÷iúimlerin ölçülmesi sa÷lanmaktadır. Hangi
sürümlerde en çok de÷iúimin yapıldı÷ı, bu de÷iúimlerin hangi
sınıflar üzerinde ne kadarlık bir etkiye sahip oldu÷u ve
bunlarla birlikte sınıfların de÷iúti÷i sürümler önerilen yöntem
sayesinde görülmektedir.
De÷iúim maliyetleri dikkate alınarak yazılımlardaki kritik
sınıflar belirlenebilir. Bu sınıflar olgunlaúmamıú ve kararsız
olabilece÷inden öncelikli olarak ve daha çok sınanmalıdır.
Ayrıca gözden geçirme ve yeniden yapılma iúlemlerinde bu
sınıflar öncelikli olarak dikkate alınmalıdır.
Yazının planı úu úekildedir. Bölüm 2’de önceki yapılan
çalıúmalardan bahsedilmiútir. De÷iúimlerin sınıflandırılması ve
hesaplama yöntemleri Bölüm 3’te, yapılan deneysel çalıúma
Bölüm 4’de açıklanmıútır. Bölüm 5 sonuçlar ve ileriki
çalıúmaları içermektedir.
Özetçe
Yazılımlar yeni özellik ekleme, kalite iyileútirme ve hata
düzeltme iúlemleri sebebiyle sürekli de÷iúime u÷ramaktadır.
Bu çalıúmada nesneye dayalı yazılımların sürümleri
arasındaki de÷iúimlerin ölçülmesi amaçlanmaktadır ve
“de÷iúim maliyeti” kavramı de÷iúimlerin miktarını göstermek
için kullanılmıútır. De÷iúim maliyetlerinin hesaplanması için
nesneye dayalı yazılımlardaki temel de÷iúimler dikkate
alınarak bir sınıflandırma yapılmıútır. Bu de÷iúimlere
etkilerine göre farklı a÷ırlıklar verilerek sınıfların de÷iúim
maliyetleri hesaplanmıútır. Bu sayede yazılımın sürümleri
arasında en çok de÷iúimin hangi sınıflar üzerinde yapıldı÷ı,
hangi sınıfların kararlı ve tekrar kullanılabilir, hangi
kısımların kararsız ve çok de÷iúen oldu÷u bilgilerine
ulaúılabilir. De÷iúim maliyeti çok yüksek olan ve yazılımın
son sürümlerine yakın kısımlarda da de÷iúime u÷rayan sınıflar
tehlikeli ve kritik sınıflar olarak ifade edilebilir. Bu kısımlar
daha çok ve öncelikli olarak sınanmalı; bakım ve yazılımın
gözden
geçirilmesi
sırasında
öncelikli
olarak
de÷erlendirilmelidir. Bu sayede proje yöneticileri sınama için
ayıracakları kaynakları daha verimli bir biçimde ayarlayabilir;
yazılım geliútiricileri yazılımın düúük kaliteli bu kısımlarından
baúlayarak yazılımın iyileútirilmesini sa÷layabilirler.
1. Giriú
Bir yazılımın tarihsel geliúim bilgisi incelemek o yazılım
hakkında daha çok bilgi edinmemizi ve daha do÷ru kararlar
vermemizi sa÷lar. Yazılımlar hayat döngüleri içersinde sürekli
de÷iúime u÷rarlar. Hata düzeltme, yeni özellik ekleme ve
kalite iyileútirme baúlıca de÷iúim nedenleridir. Ancak,
yazılımların kaliteli kısımlarında, hata çıkma olasılı÷ı di÷er
kısımlarına göre daha azdır; ayrıca iyi bir tasarımda bu
kısımlar eklenecek yeni özelliklerden az etkilenir. Di÷er
taraftan kalite özellikleri daha düúük olan sınıflar hataya
açıktır ve gelen de÷iúiklik isteklerinden çok etkilenir. Dolayısı
ile yazılımlardaki düúük kaliteli kısımlar yazılımların kritik
kısımlarıdır ve yazılımın di÷er kısımlara göre daha çok
de÷iúir.
Önceki çalıúmalarımızda [1,2] yazılımların kaynak kodundaki
“yapısal de÷iúimleri” analiz eden ve yazılımın gerçekten
de÷iúen kısımlarını bulan de÷iúim analiz yöntemi, çalıúmanın
sonuçlarının do÷rulanması için geliútirilmiútir. Bu çalıúmada
ise bu yöntem yazılımın geliúiminin incelenmesi ve
yorumlanması için kullanılmıútır.
Çalıúma kapsamında yazılımların sürümleri arası de÷iúimleri
ölçmek için “de÷iúim maliyeti” kavramı tanımlanmıútır ve bu
kavram ardıúıl iki sürüm arasındaki farkların ölçülmesi için
kullanılmıútır. De÷iúim maliyeti hesaplanırken, yazılımlardaki
2. Literatür Özeti
Bazı araútırmacılar, sistem tasarımının de÷iúebilirli÷e ve
de÷iúimin yayılmasına olan etkisini araútırmıúlardır.
M.Chaumun ve di÷erleri yaptıkları araútırmada [3] sistem
tasarımının de÷iúebilirli÷e etkisini incelemek için bir de÷iúim
etkisi modeli oluúturmuúlardır. Yazılımın bir yerinde yapılan
de÷iúimin, yazılımdaki di÷er hangi kısımları etkiledi÷ini
bulmanın; yazılımın de÷iúimden sonrada kararlı ve do÷ru
çalıúmasını sa÷lamak için önemli oldu÷unu vurgulamıúlardır.
Ana odakları, sistemin bir de÷iúimi nasıl karúılayaca÷ını ve
sistemin
de÷iúebilirli÷inin
de÷iúimleri
ne
kadar
so÷urabildi÷idir.
Bazı araútırmacılar, yeni eklenen bir özelli÷in, var olan bir
özelli÷in de÷iútirilmesinin sınıfları etkileme olasılıklarını
dikkate alarak de÷iúim e÷ilimli sınıfları olasılıksal
yaklaúımlarla belirleme üzerine çalıúmıúlardır. Tsantalis ve
di÷erleri bu konuda yaptıkları çalıúmada [4], bu yaklaúımla,
nesneye dayalı sistemlerde verilen bir de÷iúime karúılık di÷er
sınıfların de÷iúim olasılıklarını belirlemeye yönelik bir
yöntem önermiúlerdir. Sharafat ve Tahvildari’nin makalesinde
[5] yazılımların, Tsantalis ve di÷erlerin önerdi÷i yönteme
33
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
yakın olarak, kaynak kodunun geçmiú sürümleri ve UML
diyagramlarındaki ba÷ımlılıkları inceleyerek, ilerleyen
sürümlerde hangi sınıfların de÷iúece÷ini olasıksal olarak
hesaplamaktadır. Bir di÷er çalıúmada [6], [4] de kullanılan
yöntemin çok sınırlı bir versiyonunu kullanarak bir teknik
sunmuúlardır; ancak gerçekleme ya da benzeri di÷er
yöntemlerle karúılaútırma vermemiúlerdir.
Bir çalıúmada [7], yazılımın önceki sürümleri, sürüm denetim
sistemleri üzerinden incelenerek kaynak kodun bir yerinde
yapılan de÷iúimin ilgili olabilece÷i di÷er kısımları
geliútiricilere önermek için bir yöntem geliútirilmiútir.
L.Li ve A. Offut kullanıcı tarafından tanımlanarak girilen bir
de÷iúimin etkisini belirlemek için de÷iúimin ba÷ımlılık
graflarına dayalı bir sistem önermiútir [8].
Yazılımın geliúim sürecindeki metriklerin de÷iúimlerini analiz
eden, bunların projelerin ilerleyen aúamalarındaki kalite
de÷iúimi hakkında bilgi çıkarmak üzerine yapılmıú çalıúmalar
vardır.
Young Lee ve di÷erleri tarafından yapılan çalıúmada [9] fanin/out ba÷ımlılık ve uyum metrikleri ile yazılımın geliúim
davranıúlarını anlamak için açık kaynak kodlu JFreeChart
yazılımı analiz edilmiútir. Yaptıkları deneysel çalıúmada
incelenen yazılımdaki sınıf sayısı artıúı ile ba÷ımlılık ve uyum
metrikleri arasındaki iliúkiyi incelemiúlerdir. Elde edilen
sonuçlar ba÷ımlılık metriklerinin sınıf sayısı ile iliúkili
oldu÷unu göstermiútir. Uyum metri÷i için ise negatif
korelasyon bulumuútur. Yeni eklenen sınıfların, silinen
sınıflara göre fan-in metrik de÷erleri yüksek, fan-out metrik
de÷erleri ise daha düúüktür. Bu da tekrar kullanılabilirlik için
istenen bir durumdur.
Yedi çevik (agile) geliútirme yöntemi ile geliútirilen proje,
nesneye dayalı metriklerinin bu projelerdeki de÷iúimlerini ve
farklı proje içeriklerinin kaynak koddan nasıl etkilendi÷ini
belirlemek için incelenmiútir [10] Metriklerin kullanılmasının,
çevik geliútirme yöntemi ile geliútirme yapan grupların
yazılımı anlamalarını kolaylaútıraca÷ını, iyileútirmelerin ve
geliúimin sa÷lanması için günlük iúlemlerini belirlemede
yardımcı olaca÷ını ileri sürmektedirler.
Bu çalıúmada, sınıfların de÷iúim maliyetleri çıkarılmıútır.
Yapılan deneyler sırasında; yazılımların de÷iúim bilgileri,
yazılımların ardıúıl sürümlerinden elde edilmiútir.
yerinin de÷iútirilmesi yapısal olmayan de÷iúimlere örnek
olarak verilebilir ve bu tür de÷iúimler de÷iúim maliyeti
hesaplanırken ihmal edilmiútir. Nesneye dayalı yazılımların
temel bileúeni sınıflardır. Sınıflar üzerinde ekleme, silme,
taúıma ve sınıfın içinde yapılabilecek de÷iúimleri
hesaplayabilmek için; sınıfların nitelik, metot gibi sahip
oldukları alt bileúenler belirlenmiútir. Dolayısı ile yapısal
de÷iúimler belirlenirken, nesneye dayalı yazılımlardaki alt
bileúenler ve bunlar üzerinde yapılabilecek iúlemler ile
bunların aralarındaki iliúkiler dikkate alınmıútır.
øsim de÷iútirme ve sınıfların taúınması iúlemleri yapısal
de÷iúim olarak de÷erlendirilmiútir. De÷iúim analizinde bu
operasyonların
belirlenmesi
hesaplamaların
sa÷lıklı
yapılabilmesi için önem taúımaktadır. Bu iúlemlerin
belirlenemedi÷i durumda; bu iúlemlerin yapıldı÷ı yazılım
birimlerinin operasyondan önceki hali silinmiú, yeni hali
eklenmiú gibi bir etkiye sahip olmaktadır.
Farklı türdeki yapısal de÷iúimler yazılım tasarımı üzerinde
farklı etkiye sahiptir. Örne÷in bir sınıfın metodu içerisindeki
yerel de÷iúimler programın di÷er kısımlarını etkilemezken,
metodun parametre listesindeki bir de÷iúim farklı kısımları
etkileyebilir. Farklı de÷iúim türlerinin ayırt edilebilmesi için
de÷iúimlere, yazılım tasarımına etkilerine göre farklı a÷ırlıklar
verebiliriz.
Yapısal de÷iúimlerin kısaltmaları, açıklamaları, a÷ırlıkları ve
çalıúmada genel olarak kullanılan a÷ırlıklar (KA) Tablo 1’de
verilmiútir.
Tablo 1: Yapısal De÷iúimler
De÷iúim
Türü
MA
MD
FA
FD
CA
CD
R
M
MC
FTC
SCC
IIC
MLC
MRTC
MPC
3. De÷iúim Analizi
Bu çalıúmada, yazılımlardaki de÷iúimleri tasarımsal düzeyde
incelemek için, kaynak kod analizine dayalı bir yöntem
izlenmiútir ve de÷iúim sınıfları oluúturulmuútur.
3.1. De÷iúimlerin Sınıflandırılması
MLOCC
De÷iúimlerin sınıflarındırılmasında; nitelik, metot, sınıf gibi
nesneye dayalı yazılım bileúenleri, bunlar arasındaki iliúkiler
ve kaynak kod üzerindeki olası de÷iúim türleri göz önünde
bulundurulmuútur. Ayrıca, bu de÷iúim sınıflarına a÷ırlıklar
verilmesi ile hesaplanan de÷iúim maliyeti kavramı
tanımlanmıútır.
Yazılımın mimari de÷iúimleri, yazılımın geliúimsel süresince
kaynak kodu incelenerek çıkarılmıútır. Yazılımın kaynak
kodundaki de÷iúimler: yapısal de÷iúimler ve yapısal olmayan
de÷iúimler olarak iki kısıma ayrılmıútır. Yapısal de÷iúikler
yazılımın derlenen çalıútırılabilir kodunu de÷iútirirken, yapısal
olmayan
de÷iúimler
çalıútırılabilir
kodunu
de÷iútirmemektedir. Yorum ve boúluk ekleme, silme,
de÷iútirme; kod hizalama veya bir metodun sınıfın içerisinde
MAAF
MDAF
MCAF
MACM
MDCM
MCCM
Açıklama
A÷ırlık
Bir sınıfa bir metot eklenmesi sabiti
Bir sınıftan bir metodun silinmesi sabiti
Bir sınıfa bir nitelik eklenmesi
Bir sınıftan bir niteli÷in silinmesi
Bir pakete bir sınıfın eklenmesi sabiti
Bir paketten bir sınıfın silinmesi sabiti
Sınıf veya metodun isminin
de÷iútirilmesi
Bir sınıfın baúka bir pakete taúınması
Görünürlük de÷iúimi
(public/private/protected)
Nitelik tipinin de÷iútirilmesi
Sınıfın türedi÷i sınıfların de÷iúimi
Gerçeklenen arayüzün de÷iútirilmesi
Metodun yerel de÷iúiklikleri sabiti
Metodun dönüú tipinin de÷iúmesi
Metodun parametre de÷iúimi
Metodun yerel operasyon ve kontrol
de÷iúiklikleri
Metoda nitelik eriúimi eklenmesi
Metoddan nitelik eriúimi silinmesi
Metodun eriúti÷i niteli÷in de÷iútirilmesi
Metoda metot ça÷rısı eklenmesi
Metoddan metot ça÷rısı silinmesi
Metodun ça÷ırdı÷ı metodun
de÷iútirilmesi
WMA
WMD
WFA
WFD
WCA
WCD
WR
WM
WMC
WFTC
WSCC
WIIC
WMLC
WMRTC
WMPC
WMLOC
K
A
0
0
1
1
0
0
1
1
1
1
1
1
0
1
1
1
C
WMAAF
WMDAF
WMCAF
WMACM
WMDCM
WMCCM
1
1
1
1
1
1
3.2. De÷iúimlerin Hesaplanması
Burada tanımlanan de÷iúim iúlemleri ve onlara verilen
a÷ırlıklar kullanılarak, nesneye dayalı yazılımların alt
bileúenlerinin de÷iúim maliyeti hesaplanır. Bu maliyetler:
Nitelik ekleme maliyeti (FAC), nitelik silme maliyeti (FDC),
nitelik de÷iúim maliyeti (FCC); metot ekleme maliyeti
34
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
3.3. Sistem Mimarisi
(MAC), metot silme maliyeti (MDC), metot de÷iútirme
maliyeti (MCC), sınıf ekleme maliyeti (CAC), sınıf silme
maliyeti (CDC), sınıf de÷iútime maliyeti (CCC) olarak
tanımlanmıútır. De÷iúim maliyetlerinin hesaplanması ile ilgili
geliútirilen denklemler aúa÷ıda verilmiútir.
Sistem genel olarak, yazılımın ardıúıl sürümlerinden kaynak
kod analiz eden ve tersine mühendislik ile yapısal de÷iúimleri
çıkaran; verilen hesaplama yöntemlerine ve de÷iúimlere
verilen a÷ırlıkları dikkate alarak de÷iúim maliyetlerini çıkaran
alt modüllerden oluúmaktadır. Sistem mimarisi ùekil 1’de
gösterilmiútir.
Sürüm analiz modülü ardıúıl sürümlerindeki farkları çıkararak
de÷iúim veritabanına kayıt etmektedir. Burada yazılımdaki
tüm yapısal de÷iúimler çıkarılmakta ve kaydedilmektedir.
De÷iúim analizi modülü, yazılımın yaúam döngüsündeki tüm
farksal de÷iúimleri, kullanıcı tarafından verilen a÷ırlıklar ile
istenen hesaplama bilgilerini kullanarak istenen ölçüm
sonuçların elde edilmesini(4.3)
sa÷lamaktadır.
FDC = WFD
FAC = WFA
FCC = WMC + WFTC
MDC = WMD + ¦ WMDAF + ¦ WMDCM
MAC = WMA + ¦ WMAAF + ¦ WMACM
MCC = WMLC + WMLOCC + WR + WMC + WMRTC + WMPC
+ ¦ WMAAF + ¦ WMDAF + ¦ WMCAF
+ ¦ WMACM + ¦ WMDCM + ¦ WMCCM
CDC = WCD + ¦ FDC + ¦ MDC
CAC = WCA + ¦ FAC + ¦ MAC
CCC = ¦ FAC + ¦ FDC + ¦ FCC + ¦ MAC
+ ¦ MDC + ¦ MCC + WR + WM + WMC + WSCC + WIIC
Hesaplamalar sırasında, de÷iúim a÷ırlıkları sadece ilgili
de÷iúim varsa ve hesaplamaya katılması seçilmiúse
hesaplamaya katılmıútır. Bu çalıúmada de÷iúim maliyeti
hesaplanırken yapısal de÷iúim a÷ırlıkları MLC, MA, MD, CA
ve CD sabitleri hariç olmak üzere di÷erlerine “1” verilmiútir.
Metot ve sınıfların hesaplanmasında sabitlere de÷er atayarak
sadece onlar kullanılabildi÷i gibi, metot ve sınıfların sahip
oldukları veya eriútikleri nitelik ve metotların a÷ırlıkları
toplamı da dikkate alınabilir. østenirse metot ya da sınıf
ekleme, silme iúlemlerine ekstra a÷ırlık vermek için bu
sabitlere sıfırdan farklı a÷ırlık vererek de kullanılabilir.
De÷iúim maliyeti hesaplama, bu úekilde esnek yapıda
tutulmuútur. Metot ekleme, silme ve yerel de÷iúim için
sabitler kullanılması yerine metodun eriúti÷i nitelik ve
ça÷ırdı÷ı metotların a÷ırlıkları ile yerel de÷iúimler için
kontrol, döngü ve metot içi di÷er de÷iúikliklere verilen di÷er
a÷ırlıkların toplamı kullanılmıútır. Benzeri úekilde sınıflar için
de ekleme, silme ve de÷iúim maliyetleri hesaplanırken sahip
oldukları nitelik ve metotların de÷iúim maliyetleri toplamı
hesaba katılmıútır. O nedenle burada kullanılan sabitlerin
de÷erleri metot ve sınıflar için “0” olarak seçilmiútir. De÷iúim
zorlu÷unu hesaba katmak için metot de÷iúim maliyetleri
hesaplanırken metot ekleme, silme veya yerel de÷iúimine sabit
bir katsayı vermek yerine, eriúilen nitelikler ve ça÷rılan
metotların durumu dikkate alınmıútır. Benzer úekilde sınıf
silme maliyeti hesaplanırken, sabit bir katsayı yerine sınıf
içerisindeki niteliklerin ve metotların de÷iúim maliyetlerinin
toplamı kullanılmıútır. Sınıfların ilk büyüklüklerine, nitelik ve
metot maliyetleri toplamı, olan ba÷ımlılı÷ı ortadan kaldırmak
için sınıf ekleme maliyeti ihmal edilmiútir. Aksi halde de÷iúim
maliyetlerinin hesaplanması sınıfların ilk sahip oldukları
nitelik ve metot sayısına ba÷lı olacaktır.
Bu denklemler iki sürüm arasındaki de÷iúim maliyetlerinin
hesaplanması içindir. Yazılımın ardıúıl sürüm serisi analiz
edilirken, de÷iúim maliyetleri birbirini takip eden ardıúıl
sürüm çiftleri arasındaki de÷iúim maliyetlerinin kümülatif
toplamı olarak hesaplanmaktadır. De÷iúim maliyet analizi
sonrası sınıfların de÷iúim maliyetlerine göre sıralı bir liste
oluúturulmuútur.
ùekil 1: Sistem mimarisi.
De÷iúimlerin analizi kaynak kod üzerinden, soyut sentaks
a÷açları (AST) kullanılarak tersine mühendislik yöntemi ile
elde edilen yazılım modelleri üzerinden yapılmıútır. Öncelikli
olarak, kod analizi için kendi laboratuarımızda geliútirilen EQuality API’si [11] kullanılarak, yazılımların her bir sürümü
için kaynak kod soyut sentaks a÷acı ve yazılım modeli
çıkarılmıútır; daha sonra ardıúıl yazılım modelleri incelenerek
aralarındaki yapısal farklar elde edilmiútir. De÷iúimlere
verilen a÷ırlıklar ve kullanılacak denklemler göz önünde
bulundurularak, sınıfların de÷iúim maliyetleri hesaplanmıútır.
4. Deneysel Çalıúma
Deneysel çalıúmada açık kaynak kodlu JFreeChart yazılımının
ardıúıl sürümleri incelenmiútir. JFreeChart açık kaynak kodlu
güçlü bir çizim kütüphanesidir [12]. Uzun dönemli bir
projedir ve incelemek için yeteri kadar sürümü vardır. Bu
çalıúmada 07.06.2002 ile 10.09.2004 tarihleri arasında
yayınlanmıú 0.9.0 ile 0.9.21 arasındaki ardıúıl yirmi iki
sürümü incelenmiútir.
Projenin ardıúıl yirmi iki sürümü analiz edilerek sınıfların
kümülatif de÷iúim maliyetleri çıkarılmıútır. Sınıfların projenin
geliúim sürecindeki toplam de÷iúim maliyetleri büyükten
küçü÷e sıralı olarak aúa÷ıdaki ùekil 2’de verilmiútir.
35
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
kadarlık bir de÷iúim yapıldı÷ı bu grafikten görülmektedir.
Ayrıca projede hangi sürümlerde en çok de÷iúim yapıldı÷ı
bilgisine de ulaúılabilmektedir. Bu sayede projenin
kullanılacak sürümleri arasında tercih yapılırken, sürümler
arasında ne kadarlık de÷iúimin yapıldı÷ı nicel olarak ifade
edilebilir ve bu dikkate alınarak karar verilebilir.
Sınıf De÷iúim Maliyeti
3000
De÷iúim Maliyeti
2500
2000
Sürüm Toplam De÷iúim Maliyeti
1500
De÷iúim
Maliyeti
10000
9000
1000
8000
500
De÷iúim Maliyeti
7000
0
1
107 213
319 425 531 637 743 849 955
Sınıf
6000
5000
4000
3000
2000
ùekil 2: Sınıfların de÷iúim maliyeti.
1000
0
Sınıfların de÷iúim maliyetleri incelendi÷inde en üstteski 19
sınıfın maliyetinin 500’den yüksek oldu÷u görülmektedir.
org.jfree paketi altında yer alan bu sınıfların de÷iúim
maliyetleri (DM) ve kaç sürümde de÷iúti÷ini gösteren de÷iúim
sayısı (DS) Tablo 2’de verilmiútir.
Bu sınıflar bu projenin birçok sürümünde de÷iúime u÷ramıú
ve üzerlerinde çok iúlem yapılmıú sınıflarıdır. Bu nedenle
yeniden yapılandırma sürecinde bu sınıflara öncelik
verilmelidir. Bu sınıflardan en üstteki 5 sınıfın de÷iúim
miktarlarının di÷erlerine göre oldukça yüksek oldu÷u
görülmektedir.
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22
Sürüm
ùekil 3: Sürüm - sınıfların toplam de÷iúim maliyeti.
øncelenen projenin sürümleri arasında en çok de÷iúim
miktarına sahip olan 5 sınıf için her bir sürümde bir öncekine
göre de÷iúim maliyetini gösteren grafik ùekil 4’de verilmiútir.
Sürüm Sınıf De÷iúim Maliyeti
1000
Tablo 2: JFreeChart Sınıfların De÷iúim Maliyeti ve Sayısı
900
DM
DS
chart.plot.XYPlot
chart.plot.CategoryPlot
chart.plot.PiePlot
chart.renderer.AbstractRenderer
chart.demo.JFreeChartDemo
chart.axis.DateAxis
chart.axis.CategoryAxis
chart.demo.JFreeChartDemoBase
chart.axis.NumberAxis
chart.axis.ValueAxis
chart.plot.MeterPlot
chart.renderer.category.AbstractCategoryItemRender
er
data.time.TimeSeriesCollection
chart.StandardLegend
chart.renderer.category.BarRenderer
chart.renderer.xy.AbstractXYItemRenderer;
chart.JFreeChart;
chart.plot.ThermometerPlot;
chart.renderer.HorizontalBarRenderer3D;
2778
2119
1787
1303
1266
886
788
704
684
640
622
20
16
17
16
10
19
15
16
16
18
14
614
613
608
579
520
520
508
501
18
13
17
17
18
18
15
9
De÷iúim Maliyeti
800
Sınıf
700
A
B
600
500
C
D
E
400
300
200
100
0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22
Sürüm
ùekil 4: Sürüm - sınıfların de÷iúim maliyeti.
Tablo 2’de en üstte yer alan ve de÷iúim maliyetleri 1200’den
yüksek olan bu 5 sınıfın gösterimi için harf kullanılmıútır. A
XYPlot, B CategoryPlot, C PiePlot, D AbstractRenderer ve E
JFreeChartDemo sınıflarını göstermektedir. Buradan
JFreeChartDemo sınıfının 0.9.2 ve 0.9.3 sürümüne geçiúte
çok de÷iúti÷i ancak ilerleye sürümlerde kararlı hale geldi÷ini
görmekteyiz. Bu sürümler arası geçiúte bu sınıf yeniden
yapılandırılmıútır. XYPlot, CategoryPlot ve PiePlot sınıfları
son sürümlerde de çok de÷iúime u÷ramıútır; ayrıca birçok
sürümünde bu sınıflar de÷iútirilmiútir. Bu sınıfların kararsız
oldu÷unu
ve
gelen
de÷iúim
isteklerinden
çok
etkilendirildiklerini dolayısı ile sınama, gözden geçirme ve
yeniden yapılandırma iúlemlerinde bu sınıflara öncelik
verilmesi gerekti÷i söylenebilir. Bu yöntem sayesinde
projedeki sınıfların tarihsel olarak de÷iúim miktarları
görülebilmekte ve sınıfların anlaúılırlı÷ının artırılması
Projenin geliúimi boyunca projedeki sınıfların toplam
de÷iúimini ifade etmek için ardıúıl iki sürüm arasındaki
toplam de÷iúim maliyetini gösteren grafik ùekil 3’de
verilmiútir. [0.9.0-0.9.21] arasındaki ardıúıl sürümler [1-22]
aralı÷ında gösterilmiútir. Bir sürümden di÷erine geçiúte ne
36
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
sa÷lanmaktadır. Bir sınıfın çok de÷iúti÷i sürüm geçisi
incelenerek neden bu úekilde bir de÷iúikli÷e gidildi÷i
incelenebilir. Bu sayede yazılımlardaki önemli sınıflar ve
önemli de÷iúikliklerin yapıldı÷ı zamanlar daha kolay takip
edilebilir.
[7]
5. Sonuçlar
[8]
Bu çalıúmada, nesneye dayalı yazılımlarda sınıfların
de÷iúimleri yapısal olarak incelenmiú ve de÷iúim miktarını
ifade etmek için de÷iúim maliyeti tanımlanmıútır. Nesneye
dayalı yazılımlardaki olası yapısal de÷iúimler sınıflandırılmıú
ve de÷iúimlere etkilerine göre farklı a÷ırlık verilmesini ve
önerilen
denklemleri
kullanarak
bu
maliyetlerin
hesaplanmasına olanak sa÷layan bir program geliútirilmiútir.
Yazılım sürümleri arasında ne kadar de÷iúim yapıldı÷ı, en
çok hangi sınıflar de÷iúime u÷radı÷ı, hangi sınıfların kararlı
ve tekrar kullanılabilir, hangi kısımların kararsız ve çok
de÷iúen oldu÷u bilgilerine ulaúılabilir. Bununla birlikte
de÷iúim maliyeti çok yüksek olan ve yazılımın son
sürümlerine yakın kısımlarda da de÷iúime u÷rayan sınıflar
tehlikeli ve kritik sınıflar olarak ifade edilebilir. Bu sınıflara
sınama ve gözden geçirme iúlemlerinde öncelik verilmelidir.
Yazılımın geliúiminin anlaúılması, hangi sınıfların hangi
sürümlerde de÷iúime u÷radı÷ı bilgisine ulaúılabilmektedir. Bu
sayede geliútiriciler yazılımdaki temel sınıfları görme ve
onları geliúimini inceleme sahibi olurlar. Sürümler arası
geçiúte maliyetlerin ölçülmesi, bir önceki sürüme göre ne
kadar iú çıkarıldı÷ının bir ölçüsü olarak kullanılabilir.
øleriki çalıúmalarda yazılımların ilk sürümlerindeki de÷iúim
miktarının etkisini azaltmak, son sürümlere do÷ru yapılan
de÷iúimlerin etkisini artırmak için bir yaúlandırma yöntemi
geliútirilmesi
planlanmaktadır.
Ayrıca
yazılımlardaki
de÷iúimlerin niteliklerinin kullanıcıya sunulması için bir çatı
geliútirilmesi düúünülmektedir.
[9]
[10]
[11]
[12]
6. Kaynakça
[1] Eski, S., Buzluca, F., “An Empirical Study on ObjectOriented Metrics and Software Evolution in Order to
Reduce Testing Costs by Predicting Change-Prone
Classes,” IEEE Fourth International Conference on
Software Testing, Verification and Validation Workshops
(ICSTW), Berlin, Almanya, 2011, sayfa 566-571.
[2] Eski, S., Buzluca, F., Nesneye Dayalı Yazılımlarda
Sınama ve Bakım Öncelikli Sınıfların Belirlenmesi,
Yüksek Lisans Tezi, 2011, øTÜ.
[3] Chaumun, M., Kabaili, H., Keller, R., ve Lustman, F.,
Change Impact Model for Changeability Assessment in
Object-Oriented Software Systems. Science of Computer
Programming, 2002, 45(2–3):155–174.
[4] Tsantalis, N., Chatzigeorgiou, A., ve Stephanides, G.,
Predicting the Probability of Change in Object-Oriented
Systems. IEEE Transactions on Software Engineering,
2005, 31(7):601–614.
[5] Sharafat, A. R., ve Tahvildari, L., A Probabilistic
Approach to Predict Changes in Object-Oriented
Software Systems. IEEE CSMR'07, 2007.
[6] Xia, F., A Change Impact Dependency Measure for
Predicting the Maintainability of Source Code. In
Proceedings of the Annual International Computer
37
Software and Applications Conference (COMPSAC),
2004, sayı 2, sayfa 23–24.
Hassan, A. E., Holt, R. C., Predicting Change
Propagation in Software Systems. In Proceedings of the
IEEE International Conference on Software Maintenance
(ICSM), 2004, sayfa 284–293.
Lee, M., Offutt, J., Alexander, R. T., Algorithmic
Analysis of the Impacts of Changes to Object-Oriented
Software. Proceedings of the Technology of ObjectOriented Languages and Systems (TOOLS 34'00), 2000,
s.61, Temmuz 30-A÷ustos 03.
Lee, Y., Yang, J., Chang, K. H., Metrics and Evolution in
Open Source Software, Seventh International Conference
on Quality Software, QSIC 2007, 2007.
Sato, D., Goldman, A., ve Kon, F., Tracking the
Evolution of Object-Oriented Quality Metrics on Agile
Projects. Proceedings of the 8th International Conference
on Agile Processes in Software Engineering and Extreme
Programming. Haziran 18-22, 2007 - Como, øtalya.
Erdemir, U., Tekin, U., Buzluca, F., EQuality: A Graph
Based Object Oriented Software Quality Visualization
Tool, 6th IEEE International Workshop on Visualizing
Software for Understanding and Analysis (VISSOFT
2011), Eylül 29-30, 2011 - Williamsburg, Virginia, ABD.
JFreeChart: http://www.jfree.org/jfreechart