Özet. Yazılım ürün hattı (YÜH), belirli bir çalışma alanının ihtiyaçlarını karşılamak için, bileşen ve ürün seviyesinde yetenek ağacıyla uyumlu ortak yazılım bileşenleriyle hızlı bir şekilde ürün çıkartmaya dönük bir yazılım geliştirme yöntemidir. Yazılım ürün hattı yaklaşımında yazılım geliştirmeye dönük farklı çalışmalar bulunmakta olup, bileşen seviyesinde doğrulama, geçerli kılma açısından çok fazla çalışma bulunmamaktadır. Bu çalışma kapsamında, ilk aşamada her bileşen için ürün ağacı kullanılarak olası varyasyon kümeleri oluşturulmuştur. Sonrasında, birim seviyesinde testler bu varyasyon kümeleri yardımıyla tanımlanmış ve her bir varyasyon elemanı için test tanımları çıkartılmıştır. Bu sayede yazılım bileşeninin nihai ürünlerde kullanılacak farklı tipleri oluşturulan testlere göre doğrulanmış ve birim seviyesinde otomatik test tanımlarının koşturulması amaçlanmıştır.
GİRİŞ YAZILIM BİLEŞENLERİNİN KODLANMASI VE BİLEŞEN TABANLI DOĞRULANMASI Yazılım ürün hattında yazılım bileşenlerinin kodlanması normale göre farklıdır. Yazılım ürün hattı yaklaşımı alan analizine dayalı olarak oluşturulan bir alt yapıdır. Bu bağlamda bileşenler de alan analizine göre çeşitlilik gösterir. Yazılım bileşenleri çeşitli varyasyonlardan oluşmaktadır. Bu varyasyonların seçimine göre çalışan yazılım birimlerinin yetenek yönetimi yetenek ağacı kullanılarak yapılır [2].
Yazılım bileşenleri, yetenek ağacından seçilecek varyasyonlara göre farklı şekilde çalışmaktadır. Yazılım yetenek ağacının örnek bir parçası aşağıda verilmiştir.
Şekil -1 Ürün yetenek ağacı Aslında yazılım bileşeni birbirine alternatif olarak çalışan yeteneklerin hepsini içermektedir. Ancak nihai sistemde bu yetenekler aynı anda çalışmayacaktır. Beraber çalışacak yetenekler birer küme oluşturmakta olup her bir küme ayrı ayrı nihai ürünlerde kullanılacaktır. Bu durum, yazılım bileşeninin bütün yeteneklerinin aynı anda doğrulanmasını gereksiz ve etkisiz kılmaktadır. Yazılım bileşeni zaten bu yetenek kümelerini içermektedir. Bir yazılım sistemindeki hataları (bug) bulmak birim testler ile mümkün değildir. Çünkü birim testlerin yaptığı iş yazılımın en küçük parçalarını kendi içerisinde test etmektir. Bu küçük parçaların kendi içlerinde çalışıyor olması, yazılımın gerçek kullanıcılar tarafından kullanılmaya başladığı zaman bir bütün olarak çalışacağını göstermez. Bir yazılım sistemi, onu oluşturan parçaların toplamından çok daha fazlasıdır. Dolayısıyla bu bütünü test etmek için farklı yöntemler kullanmak gerekir. Fonksiyonel test ve entegrasyon testi bunlara örnek verilebilir. Ancak birim testler, yazılım birimlerini birim seviyesinde doğrulamak ve yine birim seviyesinde hataları bulmak için kullanılır.
Standart birim test yaklaşımında yazılım biriminin belli bir oranı kapsanacak şekilde birim testler yazılmaktadır. Ancak yazılım ürün hattı yaklaşımında önce de bahsettiğimiz gibi yazılım birimi birden çok varyasyonda bulunmaktadır. Yazılım biriminin bir varyasyonu diğerinin çalışmasını pozitif ya da negatif yönde etkileyebileceği için birim testlerin yetenek modeli düşünülmeden koşturulması anlamlı olmayacaktır. Bu çalışma kapsamında birim testlerin varyasyon kümelerine göre gösterdikleri değişkenliklerden bahsedilecektir.
Yetenek ağacına göre yazılım geliştirme aşamasında, yazılım birim testlerinin de yetenek ağacı baz alarak gerçeklenmesi gerekmektedir. Birim test yazılan her bir fonksiyonun olası girdileri yetenek ağacından elde edilen varyasyonlara göre oluşturulur. Bu varyasyonlar dışında herhangi bir birim test kapsamasına gerek yoktur. Varyasyon kümesinin her bir elemanı için birim test kümeleri oluşturulur. Bu birim test kümeleri sadece ilgili varyasyonu kapsamaktadır. Nihai sistemde kullanılması mümkün her bir varyasyon bu sayede birim seviyesinde doğrulanmış olur.
Bu yöntemdeki amaçlar 1) 2)
Nihai ürünlerde beraber çalışacak yeteneklerin birbirlerine yan etkilerini ortaya çıkarmak: Klasik birim test yaklaşımında bu bilgi elde edilmemektedir. Çünkü, bütün yetenekler beraber test edilmektedir ve her bir testin yan etkisi ortaya çıkarmaktadır. (bu yan etkiler: ortak bellek kullanımı, veri tabanı erişimi, işletim sistemi kaynakları kullanımı vb olabilir) Aslında hiçbir zaman oluşmayacak hatalarla uğraşılmasının engellenmesi: Klasik yaklaşımda rastgele birim test koşturulan ve birbirlerine yan etki yaratan iki yetenek nihai üründe beraber çalışmayabilir. Bu iki yeteneğin birbirlerine karşı yan etki yaratması olası ve kabul edilen bir durum olabilir. Nihai üründe hiçbir zaman beraber çalışmayacak ve birbirinin alternatifi olan bu iki yeteneği beraber doğrulamak anlamsızdır. 2.2
YETENEK AĞACININ KULLANILMASI Ürün ağacı farklı bileşen ağaçlarının birleştirilmesi yardımıyla oluşturulmaktadır. Alan mühendisliğindeki genel yetenek ağacının ୢ olduğu düşünülürse uygulama mühendisliğinden çıkacak her bir ürünün yetenek ağaçları ( ଵୟ ǡ ଶୟ ǡ ଷୟ ǥ ୬ୟ ) ǡ ୢ üzerinden türetilebilir. ୢ ise alan mühendisliğinde türetilen tüm bileşenlerin ürün ağaçlarının birleşimi ile oluşturulmaktadır. ୩ୢ bileşene ait yetenek ağacını göstermektedir.
ܷ ௗ ൌ ܤ ଵௗ ܤ ଶௗ ܤ ଷௗ ǥ ܤ ௗ Uygulama mühendisliğinde geliştirilecek bir ürün için ilk olarak alan mühendisliğindeki bileşenlerin ürün ağacı kullanılarak ürüne özgü yetenek ağaçları tanımlanmaktadır. Bu aşamada, ܤ ௗ üzerinden varyasyonlar oluşturulmakta ve her ürünün yetenek ağacı çıkartılmaktadır. Bileşen üzerinde varyasyon oluşturma işlemi ß olarak tanımlanırsa uygulama mühendisliğindeki nihai ürün ağacının oluşturulma yöntemi matematiksel olarak aşağıdaki gibi ifade edilebilir.
é ሺܷ ௗ ሻ = é ܤሺ ௗଵ ܤ ௗଶ ܤ ଷௗ ǥ ܤ
ௗ ) = ܷ ଶ
= é ሺ ܤ ଵௗ ሻ é ሺ ܤ ଶௗ ሻ é ሺ ܤ ଷௗ ሻ ǥ é
ሺ ܤ ௗ ሻ = ܷ
(
Şekil -2 Ürün yetenek ağacı oluşturma yöntemi Her bir bileşen için ܰ farklı varyasyon olacağını düşünürsek alan mühendisliğindeki yetenek ağacı kullanılarak çıkartılabilecek olası ürün sayısı aşağıdaki şekilde ifade edilebilir [1].
ܰ ௦
ൌ ς ଵ ܰ
(
YETENEK AĞACI TABANLI DOĞRULAMA YÖNTEMİ Farklı ürünler aynı yazılım bileşenlerine farklı varyasyonların bağlanmasıyla oluşturulabilmektedir. Bu sebeple, yazılım bileşenine ait metod ve sınıflar farklı ürünlerde farklı şekilde sonuç veriyor olabilirler. Yazılım mimarisine bağlı olarak metodlar varyasyon değişikliği sebebiyle değişikliğe uğramış veya metodun önkoşulları ile son koşulları sınıf değişmezlerine bağlı olarak değiştirilmiş olabilir. Bu aşamada birim testlerin uygulanacağı metodlar iki tipte incelenebilir [3]. a) İçeriği sabit olan metodlar b) İçeriği değişen metodlar (Override) Literatürde metodların testlerinin tam kapsaması düşünülerek farklı doğrulama yöntemleri önerilmektedir. Bu yöntemlerden Concolic test ile yazılım metodu beyaz kutu olarak kabul edilip olası tüm test girdileri çalıştırma yolu ağacı yardımıyla tanımlanabilmektedir [5]. Test girdileri bazı araçlar yardımıyla otomatik olarak da çıkartılabilmektedir. Bu çalışmada YÜH ‘da Concolic test yöntemi kullanılmış olup farklı yöntemlerle de test girdileri oluşturulabilir. YÜH üzerinde varyasyon bağlamasından sonra metodların çalışma şekillerinin değişeceği ve iki tip metodun oluşacağı öngörülmektedir.
YÜH ‘te Concolic test metodunu kullanarak test girdilerini oluşturduktan sonra bu
test girdileri üzerinden olası varyasyonlar için güncellemeler yapmak gerekmektedir.
Concolic test sonrası oluşturulacak veri kümeleri (
public Boolean CheckItCanShoot(Location targetloc, Location ownloc) Bu fonksiyon için tasarlanacak olan birim testlerinin farklı varyant tipleri için değerlendirilmesi gerekmektedir. Varsayılan bir varyant tipi için birim test girdileri tanımlanacak, sonrasında bu birim test girdileri varyant değişimlerine göre değişkenlik gösteren sınıf değişmezleri ile güncellenecektır. Test girdilerinin her bir varyant için baştan çıkartılmasına gerek yoktur. (b) tipindeki metodlarda ise sınıf değişmezlerinin ve concolic test yönteminin değişen her varyasyon için incelenmesi gerekmektedir. Şekil - 4 ‘te sınıf değişkenlerinin yetenek ağacı bağlantılı değişimi gösterilmektedir. Şekil -4 (b) tipi metod test seti oluşturma yöntemi (b) Tipindeki metodlarda ise Concolic test sonrası oluşturulmuş test setleri 7. denklemdeki gibi güncellenebilir. Bu koşulda varyasyonun bağlanması sonrası her metod için concolic test metodunu uygulayıp, sonrasında sınıf değişkenlerini kullanarak bu test setlerini güncellemek gerekmektedir. ܶ ଵ୩ ሺ ݃݅ݎ݀ ר ܫ Bu tipteki metodlar için test girdi seti oluşturma yöntemi aşağıdaki örnekle açıklanabilir. YÜH hattında özellik seti olarak açı tipi ve buna karşılık gelen varyant değerleri olarak da Derece, Radyan ve Grad seçilebildiğini düşünelim. (i) numaralı fonksiyon varyant tipi Derece olarak seçildiğinde yapılacak olan işlemleri göstermekte olup, (ii) numaralı fonksiyon varyant değeri olarak Radyan seçildiğinde çağırılacak olan fonksiyondur. YÜH ‘dan çıkacak ürünlerde sadece Derece cinsinden bir varyant kullanımı seçilebilir veya Radyan ile birlikte Derece kullanımı seçilebilir. Varyant seçimleri bu fonksiyonları direk etkileyeceğinden dolayı fonksiyonların isimleri aynı kalmasına rağmen fonksiyonların iki duruma göre farklı yazılması gerekmektedir. (7) (i) //when Default Degree
public float CalculateAngleBetweenPos(float targetangle1, float targetangle2) (ii) //when Radian
public override float CalculateAngleBetweenPos(float targetangle1, float targetangle2) Yetenek ağacı yardımıyla ürün oluşturulurken direk etkilenebilecek olan bu tipteki fonksiyonlar için test girdilerinin baştan oluşturulması gerekmektedir. Birim testlerin yetenekler ürüne eklendikten sonra yapılması daha uygun olacaktır. Örneğin yukarıdaki örnek için 3 farklı test veri setinin kullanılması gerekmektedir. Bu çalışma kapsamında YÜH kullanılarak geliştirilen yazılımların birim testlerinin farklı ürün varyasyonları kapsamında çıkartılmasına dönük bir yöntem önerilmiştir. Bu yöntem ile farklı yeteneklerin varyasyon seçimlerine bağlı olarak birim test girdileri güncellenmiştir. Tüm varyasyonların birlikte çalışamayacağı düşünüldüğünde nihai ürün içerisinde yer alabilecek varyasyonların seçilip bu varyasyonlara göre test girdilerinin şekillendirilmesi önemlidir. Test etkisinin incelenmesi gelecekte yapılacak bir çalışma olarak değerlendirilebilir. YÜH ‘da geleneksel yöntemlerle birim testlerinin gerçekleştirilmesi ve aynı yazılımda bu önerilen yöntemle birim testlerinin gerçekleştirilmesi sonrasında test etkisindeki değişim incelenebilir. Test girdilerinin yetenek bağlanması sonrasında bir yazılım yardımıyla otomatik olarak çıkartılması amaçlanmakta olup gelecek bir çalışma olarak hedeflenmektedir. 5
REFERANSLAR