=Paper=
{{Paper
|id=None
|storemode=property
|title=Yazılım Havuzu Analizi ile Tasarım-Kod Uyumluluğunun Araştırılması
|pdfUrl=https://ceur-ws.org/Vol-1072/submission50.pdf
|volume=Vol-1072
|dblpUrl=https://dblp.org/rec/conf/uyms/CaglayanD13
}}
==Yazılım Havuzu Analizi ile Tasarım-Kod Uyumluluğunun Araştırılması==
https://ceur-ws.org/Vol-1072/submission50.pdf
Yazılım Depolarının Analizi ile Tasarım – Kod
Uyumluluğunun Araştırılması
Kadriye ÖZBAġ ÇAĞLAYAN1, Ali H. DOĞRU2
1
TÜBĠTAK-BĠLGEM Yazılım Teknolojileri AraĢtırma Enstitüsü, ANKARA
2
ODTÜ Bilgisayar Mühendisliği Bölümü, ANKARA
kadriye.caglayan@tubitak.gov.tr
dogru@ceng.metu.edu.tr
Özet. Yazılım projelerinde analiz aĢamasında tanımlanan probleme çözüm
üretme aĢaması olan tasarım, geliĢtiriciler tarafından yazılımı gerçekleĢtirmek
üzere yürütülen kodlama sürecine girdi sağlar. Yazılım geliĢtirilirken ya da
güncellenirken, kod ve tasarımın uyumlu olarak idamesi uzun vadeli bir yatı-
rımdır ve idame ettirilebilir bir proje sonucunu doğurur. Ancak gerçek hayatta
tecrübesizlik, bilgi eksikliği ya da tasarımın atıl kalmıĢ olması gibi sebeplerle
geliĢtiricilerin tasarımla tam olarak tutarlı kod gerçekleĢtiremediği durumlar ya-
Ģanabilmektedir. Tasarım ile uyumsuzluk ise kalite açısından tahmin edilemez
bir kod oluĢmasına sebep olur. Tasarım ile kod arasındaki uyumluluğun kontrol
edilmesi faydalı ancak iĢ gücü yoğun bir iĢlemdir. Uyumluluğun kontrolü amacı
ile yazılım depolarının analizinin yapılması, tersine mühendislik ve manuel
kontrol süreçlerinde karĢılaĢılan güçlüklerin üstesinden gelinmesini sağlayacak
ve zamanda yazılım geliĢtirme / idame süreçlerinin yöneticilerine değerli bilgi-
ler sunacaktır. Bu çalıĢmada kod – tasarım arasında uyumluluğun belirlenmesi
amacı ile yazılım depolarının analiz edilmesi için geliĢtirilen yaklaĢım ile bu
yaklaĢımın örnek bir sürüm üzerinde uygulaması anlatılmaktadır.
1 Giriş
Yazılım geliĢtirme projelerinde, analiz aĢamasında belirlenen soruna çözüm tasarım
aĢamasında oluĢturulduğundan ötürü, tasarım oldukça önemli bir aĢamadır. Tasarım
aĢamasında alternatifler arasından en iyi tasarım seçimi ile birlikte çözüm kararları da
alınır. Tasarımda belirlenen çözüm ve tasarım bileĢenler, daha sonraki aĢamada bir ve
daha fazla geliĢtirici tarafından yürütülen kodlama aĢaması ile gerçekleĢtirilerek
tasarım kaynak koduna dönüĢtürülür. Bu nedenle, üretilen kaynak kodunun çözümü
tanımlayan tasarım ile uyumlu olması beklenir.
Tasarım, yazılım geliĢtirilirken ya da bakımı yapılırken üretilen yazılımın karma-
Ģıklığını azaltmaya yardımcı bir unsurdur. Kaynak kodu ve tasarım arasında uyumlu-
luğu korumak yüksek kaliteli ve sürdürülebilir bir proje için uzun vadeli bir yatırım-
dır. Ancak gerçek hayatta tecrübesizlik, bilgi eksikliği ya da yazılımın yaĢlanması
sonucu tasarımın atıl kalmıĢ olması [1] gibi sebeplerle geliĢtiricilerin tasarımla tam
olarak tutarlı kod gerçekleĢtiremediği durumlar yaĢanabilmektedir. Bazı araĢtırmacı-
lar bu sorunları tasarım ilkelerine uyulmamasına [2] ve tasarım kalıplarının kullanıl-
mamasına [3] dayandırır; özellikle de yazılım geliĢtirme ve bakım aĢamalarında bu
konuların dikkate alınması konusuna vurgu yapar [4]. Tasarım ile uyumsuzluk ise
kalite açısından tahmin edilemez bir kod oluĢmasına sebep olur.
Tasarım ile kod arasındaki uyumluluğun kontrol edilmesi faydalı ancak iĢ gücü
yoğun bir iĢlemdir. Çünkü bu iĢlem kodun tersine mühendislik yaklaĢımı ile tasarıma
dönüĢtürülmesini ve hedeflenen tasarım ile manuel olarak uyumluluğunun kontrol
edilmesini gerektirir. Kod – tasarım uyumluluğunun kontrolü amacı ile yazılım ürün-
lerinin saklandığı yazılım depolarında analizler yapılması, tersine mühendislik ve
manuel kontrol süreçlerinde karĢılaĢılan güçlüklerin üstesinden gelinmesini sağlaya-
caktır. Benzer Ģekilde, kod – tasarım arasındaki uyumluluğun incelenmesi, yazılım
geliĢtirme / idame süreçlerinin yöneticilerine değerli bilgiler sunacaktır.
Bu çalıĢmada, tasarım ve kod uyum düzeylerini analiz etmek yazılım deposu analiz
yöntemi ve kısmen metin madenciliği teknikleri kullanılması hedeflenmektedir.
Makalenin geri kalan kısmı Ģu Ģekilde düzenlenmiĢtir: 2. bölümde ilgili literatür
gözden geçirilmiĢtir. 3. bölümde tasarım-kod uyumluluğu analizi için izlenen yöntem
açıklanmaktadır. 4. bölümde tasarım-kod uyumluluğunu değerlendirmek için yapılan
örnek analiz çalıĢmasının sonuçları sunulmuĢtur. Son bölümde ise bu çalıĢmanın so-
nuçları ve gelecek çalıĢmalar özetlenmiĢtir.
2 İlgili Çalışmalar
Yazılım mühendisliği araĢtırmacıları, yazılımın geliĢimi ve değiĢimi bağlamında yazı-
lım depolarından iliĢkileri ve eğilimleri ortaya çıkarmak için geniĢ bir yelpazede farklı
yaklaĢımlar geliĢtirdiler. Yazılım depolarından yapısal kaynak kodu değiĢiminin tespit
edilmesi için geliĢtirilen bir araç [5]'te verilmiĢtir. Söz konusu araç ile parametre /
değiĢken / metot ekleme / kaldırma; bir değiĢkenin / metodun gizlenmesi / açılması /
isim değiĢikliği; gizlemek / açmak / yeniden adlandırma; özniteliğin / metodun / sını-
fın yerinin değiĢtirilmesi; süper sınıf / arayüz / sınıf bilgisinin çıkartılması gibi deği-
Ģim türleri tespit edilebilmektedir.
Kaynak kodu ile birlikte test kodunun değiĢiminin eĢgüdümü, bir projenin sürüm-
leri için kod kapsama oranları ve test / kaynak kodlarının boyutları incelenerek tespit
edilmiĢtir [6].
Levenshtein mesafesi algoritması ile bilgi çekme teknikleri (Vektör Uzayı Modeli)
birleĢtirerek CVS depolarındaki kaynak kodları analiz edilmiĢ, kod satırı düzeyinde
değiĢiklikleri tespit etme yöntemi tanımlanmıĢtır [7].
Kodlama ve tasarım arasındaki uyumluluk kontrolleri ile ilgili olarak literatürde
geçen eserler arasında yer alan Yazılım Yansıma Modeli [8] tekniği ile projenin bir iĢ
ürününün (örneğin, tasarım modeli), bir baĢka iĢ ürünü (örneğin, kaynak kodları) ile
uyumlu ya da uyumsuz olduğu noktaları özetleyerek yazılım mühendislerine yardımcı
olmayı hedeflemektedir.
Kullanım durumları ile kaynak kodları arasındaki izlenebilirlik iliĢkilerinin otoma-
tik olarak kurulabilmesine ya da hatalı olarak kurulmuĢ izlenebilirlik iliĢkilerinin
tespit edilmesine yönelik olarak bir çözüm sunmak üzere geliĢtirilen LeanArt aracı,
geliĢtirici tarafından örnek olarak kurulan izlenebilirlik iliĢkilerinden derlenen bilgi-
lerle diğer izlenebilirlik iliĢkilerini tahmin etmeye çalıĢır [9]. LeanArt otomatik öğ-
renme yöntemi olan Çok Stratejili Öğrenme YaklaĢımı (Multistrategy Learning App-
roach) ile geliĢtirilmiĢ olup kullanım durumu adları ile kod elemanları isimleri arasın-
da birebir uyum olmasa da izlenebilirlik iliĢkilerini tespit edebilmeyi hedeflemektedir.
Nesne-yönelimli tasarımın ilgili kaynak kodu ile uyumunu kontrol etmek için Dü-
zenleme Mesafesi’nin hesaplanması ve maksimum eĢleĢme algoritmasından faydala-
nan bir yöntem [10]’de sunulmuĢtur. Bu yöntemde C++ kaynak kodlarından mevcut
tasarım çıkartılır ve gerçek tasarım ile karĢılaĢtırılarak tutarsızlıklar bulunur. Önerilen
yöntemin çıktısı, her eĢleĢen sınıf için benzerlik ölçütleri ve eĢleĢmeyen sınıflar kü-
mesi Ģeklinde sunulmaktadır.
UML modellerinin yapısal farklılaĢmalarını tespit etmeye yönelik olarak önerilen
UMLDiff algoritması baz alınarak nesne yönelimli yazılım sistemlerinin değiĢimini
analiz eden bir yöntemde [11] ise tasarım değiĢimlerinin analizi, kaynak kodunun
ardıĢık olarak bir dizi anlık durumunu girdi alarak gerçekleĢtirilir.
3 Kod-Tasarım Uyumluluğu Analizi Yaklaşımı
Bu çalıĢmada, artırımlı yinelemeli yaĢam döngüsü kullanılan ve toplamda 5 farklı
sürüm yayınlanan bir projede ilk (v1.0) ve son sürümünden (v4.1) elde edilen veriler
analiz edilmiĢtir. Artırımlı yinelemeli yaĢam döngüsünün her bir yinelemesinde sis-
teme yeni özellikler eklenir ve mevcut özellikler kullanıcı geri bildirimleri doğrultu-
sunda iyileĢtirilir. Her yineleme analiz, tasarım, kodlama ve sistem testleri aĢamala-
rından oluĢur ve projenin iĢ ürünleri her yinelemede bu aĢamalarında sonunda daya-
naklandırılır. Bu çalıĢmada, tasarım aĢaması sonunda dayanaklandırılan tasarım mo-
delinden elde edilen veriler ile ve sistem testlerinin sonunda dayanaklandırılan kaynak
kodundan elde edilen veriler kullanılmıĢtır. Söz konusu veriler Enterprise Architect
aracı ile UML 2.1 notasyonu kullanılarak oluĢturulmuĢ tasarım modeli ve Java prog-
ramlama dili kullanılarak geliĢtirilmiĢ kaynak kodlardan elde edilmiĢtir. Veriler elde
edilirken, öncelikle tasarım modelinden sınıf tanımlarını içeren kod Enterprise Archi-
tect aracı kullanılarak üretilmiĢ, tasarımdan üretilen kodda ve gerçekte geliĢtirilen
kodda yer alan sınıf tanımları, bu çalıĢma kapsamında geliĢtirilen bir metin ayrıĢtırıcı
kullanılarak çıkartılmıĢtır.
Bu makale kapsamında tasarım ve kod arasında uyum incelenirken, tasarımda sa-
dece statik özelliklerin modellendiği sınıf tanımları ve kalıtım (inheritance) ve gerçek-
leĢtirim (implementation) iliĢkileri dikkate alınmıĢtır. Bu bağlamda yazarlar, dinamik
özelliklerin modellendiği sıralama (sequence) ve aktivite diyagramları gibi tanımların
yanı sıra birlik (association) ve birleĢtirme (composition) iliĢkilerinin de incelenmesi-
nin çalıĢmada sunulan yaklaĢımı zenginleĢtireceğini ve sonuçları daha iyileĢtireceğini
değerlendirmekle birlikte söz konusu incelemeleri ileriki aĢamalarda yapılacak çalıĢ-
malara bırakmıĢlardır. Tasarım ve sistem testleri dayanaklarından çıkartılan sınıf ta-
nımlarını içeren ham veri iĢlenerek, sınıf tanımları aĢağıdaki öznitelikleri içerecek
Ģekilde yapısal bir duruma getirilmiĢtir:
Adı (String) - Sınıfın adı
EriĢimTürü (Sayısal) – public / private / protected sınıf
SınıfMı (Sayısal) - class veya interface olduğu
SoyutMu (Sayısal) - soyut bir sınıf / arayüzü olup olmadığı
FinalMi (Sayısal) - final bir sınıf / arayüzü olup olmadığı
Extends (0 .. n) (String) - Sınıf tarafından extend edilen sınıflar
Implements (0 .. n) (String) - Sınıf tarafından implement edilen sınıflar
Kodda yer alan bir sınıf tanımı ile tasarımda yer alan bir sınıf tanımının tam olarak
eĢleĢme karĢılaĢtırması, yukarıda listelenen özniteliklerin tümü karĢılaĢtırılarak
yapılmakta ve yalnızca tüm öznitelikler aynı ise kod ve tasarım sınıfları uyumlu
olarak kabul edilmektedir. Özniteliklerden herhangi birisi kod ve tasarımda aynı
değilse, kod ve tasarım sınıfları uyumsuz kabul edilmiĢtir. Veri analizleri RapidMiner
(Text Processing özelliği ile) kullanılarak yapılmıĢtır.
4 Uyumluluk Analizi Sonuçları ve Tartışma
Veri analizinde ilk adım olarak, tasarım ve kodda yer alan sınıfların sayıları tespit
edilmiĢ, bu sınıflardan sınıf isimleri birebir eĢleĢen sınıf sayıları belirlenmiĢtir. Kod
ve tasarım arasında uyumu irdelemek amacı ile tam olarak eĢleĢen sınıf tanımları
bulunmuĢtur. 3. Bölüm’de de açıklandığı gibi, tam olarak eĢleĢme analizi yukarıda
belirtilen özniteliklerin tamamında eĢleĢme kontrolü yapar; yani sınıflar tüm özniteli-
klerinin eĢleĢmesi durumunda uyumlu, aksi takdirde uyumsuz olarak sayılır.
Tablo 1. Sürümlere Göre Tasarım ve Kod Ölçümleri
Proje Ölçümleri Sürüm v1.0 Sürüm v4.1
Tasarımdaki Sınıf Sayısı 337 1144
Koddaki Sınıf Sayısı 2344 3118
Tasarım ve Kodda Aynı Ġsimli Sınıfların Sayısı 108 845
Tasarım ve Kodda Aynı Ġsimli Sınıfların Yüzdesi 53 74
Tasarım ve Kodda Tam Olarak EĢleĢen Sınıfların Sayısı 95 336
Tasarım ve Kodda Tam Olarak EĢleĢen Sınıfların Yüzdesi 4 11
Tasarım Kalıpları ile Uyumlu Kod Sınıflarının Sayısı 771 2279
Tasarım Kalıpları ile Uyumlu Kod Sınıflarının Yüzdesi 33 73
Tablo 1’de yer alan ölçüm sonuçları incelendiğinde, sınıf isimleri açısından tasarım
ve kodlama arasında ~% 50 - % 75 arası birebir uyum söz konusudur. Tasarım ve kod
arasında tam olarak (tüm öznitelikleri birebir) eĢleĢen sınıf tanımlarına bakıldığında
ise çok daha düĢük seviyelerde eĢleĢme olduğu görülmektedir (~% 4 - % 11).
Bu sonuçlar ile ilgili proje ekibi ile yapılan görüĢmeler üzerine, tasarımda birbirini
tekrarlayan durumlar için tek bir örnek kalıba yer verildiği, bu tasarım kalıbına karĢı-
lık kodda pek çok sınıf bulunabildiği anlaĢılmıĢtır (örneğin, “tüm XXXView sınıfları
IProjectView sınıfını “implement” etmelidir” kalıbı tasarımda bir kez belirtilir ancak
bu kalıp ile uyumlu olarak kodda 75+ XXXView sınıfı mevcuttur). Bu tespitin ardın-
dan, bahsi geçen tasarım kalıplarını temsil etmek üzere düzenli ifadeler (örneğin,
sınıf adı *View Ģeklinde geçiyorsa bu sınıf tanımının devamında “implements IPro-
jectView” ifadesi de geçmelidir kuralını ayrıĢtıran kurallar) tanımlanarak tasarım
kalıbı ile örtüĢen sınıf tanımları tespit edilmiĢtir. Bu düzenli ifadeler, öncelikle tara-
Ģım tanımında kontrol edilmiĢ, tasarımda bu kurala uygun bir sınıf tanımı varsa kodda
kurala uyan tüm sınıflar tasarım ile uyumlu sayılmıĢtır. Söz konusu iyileĢtirmenin
ardından tasarım ve kod sınıfları arasındaki eĢleĢme oranları öenmli ölçüde artmıĢtır
(% 33 - % 73).
Tablo 1'de verilen sonuçların da özetlediği gibi kod ve tasarım arasındaki uyum
düzeyleri proje ilerledikçe yükselmektedir. Bu sonuçlar arkasındaki nedenlerinden
biri, iĢ kuralı kontrolü, uyarı ve hata mesajı sınıfları gibi birbirine çok benzer ancak
son derece basit tanımı olan sınıflar kodda mevcut olmakla birlikte tasarımda mevcut
değildir (ilk sürümdeki sınıfların yaklaĢık olarak % 40’ı bu tür sınıflardır). Diğer bir
neden de bir sınıfın tasarımdaki tanımına ilave olarak bir baĢka sınıfı da “extend”
etmesi gibi durumlarda uyumun yok sayılması, sadece tam uyuma odaklanılması ve
kısmi uyumun herhangi bir Ģekilde sayılmamasıdır.
5 Sonuçlar ve Gelecek Çalışmalar
Bu makalede, tasarım ve kod arasındaki uyumluluğu belirlemek için yazılım depola-
rında yer alan tasarım modeli ve kaynak kodlarının eĢleĢme analizi için bir yaklaĢım
sunulmuĢtur. Sınıf tanımları arasındaki tam eĢleme ve sonrasında düzenli ifadeler
kullanılarak tasarım kalıpları ile kod arasında eĢleĢme durumları incelenmiĢtir. Tasa-
rım kalıplarının dikkate alındığı durumda tasarım ve kod arasındaki uyum düzeyleri-
nin oldukça iyileĢtiği görülmüĢtür.
Daha sonraki aĢamalarda yapılacak çalıĢmalarda tam uyuma ek olarak kısmi uyu-
mun da dikkate alınmasına yer verilebilir. Düzenli ifadeler tanımlayarak tasarım ka-
lıplarına uyumu incelemek yerine bu kalıpların veri madenciliği / metin madenciliği
teknikleri ile tespit edilmesi de çalıĢmanın önemli bir açılımı olacaktır. Ayrıca, tasa-
rım modeli ve kaynak kodların eĢleĢme analizlerinde sıralama (sequence) ve aktivite
diyagramları gibi dinamik modelin yanı sıra birlik (association) ve birleĢtirme (com-
position) iliĢkilerinin de incelenmesi çalıĢma sonuçlarının doğruluğunu artıracaktır.
Kaynaklar
1. Parnas D.L.: "Software aging," 16th Int. Conf. on Software Engineering, Soronto, Italy
(1994) 279-287
2. Martin R. C.: Agile software development: principles, patterns and practices, Prentice Hall,
(2003)
3. Gamma E., Helm R., Johnson R., Vlissides J.: Design patterns: elements of reusable object-
oriented software, Addison Wesley (1995)
4. Chatzigeorgiou A., Manakos A.: “Investigating the evolution of bad smells in object-oriented
code,” 7th International Conference on the Quality of Information and Communications
Technology (2010)
5. Gerlec C., Krajnc A., Heričko M., Božnik J.: “Mining source code changes from software
repositories,” 7th Central and Eastern European Software Engineering Conference in Russia
(2011)
6. Zaidman A., Rompaey B. van, Demeyer S., van, Deursen A.: “Mining Software Repositories
to Study Co-Evolution of Production & Test Code,” 1st International Conference on Softwa-
re Testing, Verification, and Validation (2008)
7. Canfora G., Cerulo L., Di Penta M.: “Identifying Changed Source Code Lines from Version
Repositories,” 4th International Workshop on Mining Software Repositories (2007)
8.Murphy G. C., Notkin D., Sullivan K. J.: “Software Reflexion Models: Bridging the Gap
between Design and Implementation,” IEEE Transactions on Software Engineering, Cilt No
27, 364-380 (2001)
9. Grechanik M., McKinley K., Perry D.: “Recovering And Using Use-Case-Diagram-To-
Source-Code Traceability Links,” 6th Joint Meeting of the European Software Engineering
Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineer-
ing (2007)
10.Antoniol G., Potrich A., Tonella P., Fiutem R.: “Evolving object oriented design to improve
code traceability,” 7th International Workshop on Program Comprehension (1999)
11.Xing Z., Stroulia E.: “Analyzing the Evolutionary History of the Logical Design of Object-
Oriented Software,” IEEE Journal on Software Engineering (2005) 850-868