Nesneye Dayalı Yazılımlarda Yapısal Değişimlerin Analizi ve
Transkript
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