Ö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 bilgiler 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.
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
uyumluluğu korumak yüksek kaliteli ve sürdürülebilir bir proje için uzun vadeli bir
yatırımdı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 [
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ünlerinin 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ğlayacaktı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 sonuç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ç [
Kaynak kodu ile birlikte test kodunun değiĢiminin eĢgüdümü, bir projenin
sürümleri için kod kapsama oranları ve test / kaynak kodlarının boyutları incelenerek tespit
edilmiĢtir [
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 [
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
otomatik 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
bilgilerle diğer izlenebilirlik iliĢkilerini tahmin etmeye çalıĢır [
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
faydalanan bir yöntem [
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
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 sisteme yeni özellikler eklenir ve mevcut özellikler kullanıcı geri bildirimleri doğrultusunda iyileĢtirilir. Her yineleme analiz, tasarım, kodlama ve sistem testleri aĢamalarından oluĢur ve projenin iĢ ürünleri her yinelemede bu aĢamalarında sonunda dayanaklandırılır. Bu çalıĢmada, tasarım aĢaması sonunda dayanaklandırılan tasarım modelinden 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 programlama 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 Architect 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 sadece statik özelliklerin modellendiği sınıf tanımları ve kalıtım (inheritance) ve gerçekleĢ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 incelenmesinin ç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 tanı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
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 özniteliklerinin 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 Sürüm v1.0 337 2344 108 53 95 4 771 33
Sürüm v4.1 1144 3118 845 74 336 11 2279 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ından, 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 IProjectView” 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
Bu makalede, tasarım ve kod arasındaki uyumluluğu belirlemek için yazılım depoları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. Tasarım kalıplarının dikkate alındığı durumda tasarım ve kod arasındaki uyum düzeylerinin oldukça iyileĢtiği görülmüĢtür.
Daha sonraki aĢamalarda yapılacak çalıĢmalarda tam uyuma ek olarak kısmi uyumun da dikkate alınmasına yer verilebilir. Düzenli ifadeler tanımlayarak tasarım kalı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, tasarı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 (composition) 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