• Sonuç bulunamadı

Yazılım Ürün Hatları için Özellik Yönelimli Test Modellerinin Yönetimi

N/A
N/A
Protected

Academic year: 2021

Share "Yazılım Ürün Hatları için Özellik Yönelimli Test Modellerinin Yönetimi"

Copied!
12
0
0

Yükleniyor.... (view fulltext now)

Tam metin

(1)

Yazılım Ürün Hatları için Özellik Yönelimli Test

Modellerinin Yönetimi

Tuğkan Tuğlular1, Mutlu Beyazıt2 ve Dilek Öztürk1

1 Department of Computer Engineering, Izmir Institute of Technology, Izmir, Turkey tugkantuglular@iyte.edu.tr

dilekozturk@iyte.edu.tr

2 Department of Computer Engineering, Yaşar University, İzmir, Turkey mutlu.beyazit@yasar.edu.tr

Özet. Bu çalışma, yazılım ürün hatlarında çok fazla sayıda olabilecek olan

özel-liklere ve ürünlere ait test modellerinin yönetimini oluşturan süreçler ile ilgili bütünsel bir yaklaşım önermektedir. Bir yazılım ürün hattı özelliklerine ve ürün-lerine ilişkin test modellerinin yönetimi; özellik test modeli oluşturma, özellik test modeli doğrulama, ürün için test modellerini birleştirme ve ürün test modeli doğrulama süreçlerinden oluşmaktadır. Bu bildiride, test modellerinin yazılım ürün hatları için özelleştirilmiş olay sıra çizgeleri olduğu bir ortamda, bu model-lerin doğrulanmasına ilişkin bir yöntem ile ürün yapılandırması sonucunda ortaya çıkan ürüne ait olay sıra çizge test modelinin doğrulanmasına ilişkin bir yöntem önerilmektedir.

Anahtar Kelimeler: Yazılım Ürün Hatları, Model-tabanlı Test, Olay Sıra

Çiz-gesi, Özellik Modeli.

Management of Feature-Oriented Test Models for

Software Product Lines

Abstract. This study suggests a holistic approach for the processes entail in the

management of test models belonging to features and products in software prod-uct lines, which may be very large in numbers. Management of test models re-garding to features and products of a software product line is composed of build-ing feature test models, verification of feature test models, composition of feature test models to obtain product test model, and verification of product test models. In this paper, a method for the verification of feature test models, which are ex-tended event sequence graphs for software product lines, and another method for the verification of product test models, which are event sequence graphs, are pro-posed.

Keywords: Software Product Lines, Model-based Testing, Event Sequence

Graph, Feature Model.

(2)

1

Giriş

Yazılım ürün hatlarının (YÜH) model tabanlı test otomasyonu vizyonu içinde önemli parçalardan biri özelliklere ve ürünlere ait test modellerinin yönetimidir. Model yöne-limli yazılım mühendisliği; oluşturma, dönüştürme, doğrulama ve birleştirme etkinlik-leri aracılığı ile modeletkinlik-lerin yönetilmesi ile ilgilenir [1]. Model yönelimli yazılım mü-hendisliğinde modellerin doğrulanması en zor konulardan biri olarak tanımlanmaktadır [2]. Bu çalışmada, yazılım ürün hatlarında çok fazla sayıda olabilecek olan özelliklere ve ürünlere ait test modellerinin yönetimi hedeflenmiştir. Bir yazılım ürün hattı özel-liklerine ve ürünlerine ilişkin test modellerinin yönetimi özellik test modeli doğrulama, ürün için test modellerini birleştirme ve ürün test modeli doğrulama etkinliklerinden oluşmaktadır. Bu çalışmada anılan etkinlerin her biri için bir yaklaşım önerilmektedir.

Yazılım ürün hatları açısından bakıldığında bir özellik (İng. feature), sistem gerek-sinimlerini karşılayan ve potansiyel yapılandırma seçenekleri sağlayan bir fonksiyonel-lik birimidir [3]. Bir başka tanıma göre özelfonksiyonel-lik söz konusu yazılımın kullanıcıları için bir anlamı olan ayırt edilebilir yazılım karakteristiğidir [4].

Kang et al. [5] tarafından ortaya atılan özellik şamaları yazılım ürün hatlarında ya-pılandırma seçeneklerini ve özelliklerin bağımlılıklarını temsil etmek için kullanılmak-tadır. Örnek bir YÜH özellik şeması Şekil 1’de verilmektedir. Kök YÜH’ü ve düğümler de zorunlu veya isteğe bağlı özellikleri temsil etmektedir. VEYA (İng. OR) ilişkisi olan özellikler bir üründe farklı birleşimlerde bulunabilir. İki özellik arasında DIŞLAYAN VEYA (İng. XOR) ilişkisi varsa bunlardan yalnızca biri YÜH’te yer alabilir. Özellik şemalarında aynı zamanda GEREKTİRME ve DIŞLAMA ilişkileri de bulunabilir. Bu-rada ilk ilişki bir özelliğin gerektirdiği diğer özellik olmadan olamayacağını, ikincisi ise özelliğin dışlanan bir diğerini göz ardı ettiğini göstermektedir.

Şekil 1. FeatureIDE [6] Kullanılarak Oluşturulan İçecek Otomatı Yazılım Hattı Özellik Şeması

[8] ([7]’den değiştirilmiştir)

Özellik şemaları genellikle kullanıcı merkezlidir. Özellik modelleri, özellik şemala-rının biçimsel gösterimleridir. Ürün şemaları ise, ürün için seçenekler ve seçimlerle ilgili tüm kararların alındığı ve gerekli bağımlılıkların somutlaştırıldığı ürün yapılan-dırmasının kullanıcı merkezli gösterimleridir. Bu bildiride, [8]’de yayınlanan çalışma-nın devamı olan adımlar yer almaktadır. Tutarlılık açısından [8]’de kullanılan örnekler

(3)

aynen alınmıştır. Tablo 1’de soda otomatı YÜH için ürün yapılandırmaları verilmekte-dir. Bu tabloda USD-Soda-Tea adı verilen ürün için ServeSodaBeverage, Serve-TeaBeverage, CancelPurchase ve USDPurchase özelliklerini göstermektedir.

Tablo 1. FeatureIDE Kullanılarak Oluşturulan İçecek Otomatı Yazılım Hattı Ürün

Yapılandır-malarına İlişkin Özellik Seçimleri

İşlevsel test hedefine yönelik test modelleri genellikle UML etkinlik diyagramları, sınırlı durum makinaları gibi davranışsal modellerden oluşturulur. Bu çalışmada test modeli olarak yazılım ürün hatları için özelleştirilmiş olay sıra çizgeleri (OSÇ) kulla-nılmıştır [8]. Yazılım ürün hatları için özelleştirilmiş OSÇ’lerin çizilmesi için web ta-banlı bir uygulama geliştirilmiştir [9]. Bu çalışmada ise, YÜH’lerinde kullanılan test modellerinin yönetimi için yeni bir yaklaşım ortaya konulmuştur.

İzleyen kısımda önerilen iki yöntem açıklanmıştır. Bir sonraki kısımda YÜH’lerde test modellerinin yönetimi süreci etkinlik bazında açıklanmış ve bütünsel bir yaklaşım sunulmuştur. Örnek çalışma kısmında ise örnek bir YÜH için önerilen yöntemlerin ça-lışma zamanları ortaya konmuştur. Sonuç bölümünde önerilen yöntemlerin ve bütünsel yaklaşımın önemi vurgulanmıştır.

2

Özellikli Olay Sıra Çizgelerinin Doğrulanması

Bu kısımda YÜH’lerde OSÇ’leri kullanarak modelleme ve oluşturulan modellerin doğrulanmasıyla ilgili önerilen yaklaşım anlatılmaktadır.

2.1 Temel Tanımlar

Bu çalışmada aşağıdaki özellik modeli ve ilgili ürün yapılandırma, yani özellik se-çimi, tanımları kullanılmaktadır.

(4)

Tanım 1. B = {yanlış, doğru}, Boole değerlerini içeren tanım kümesi ve F, Boole

değişkenleri içeren sonlu bir küme olsun. F sınırlı bir Boole değişkenleri kümesi (özel-likler) olsun. Bir özellik modeli (ÖM) fm: (F → B) → B, F kümesi üzerinde tanımlı bir önerme formülü olarak verilir [10]. n

Tanım 2. Bir ürün yapılandırması (ÜY) pc: F → B, özelliklere fm(p) = doğru

eşitli-ğinin sağlayacak şekilde Boole değerlerinin atanmasıdır [10]. n

Bu çalışmada YÜH’ler üzerinde model tabanlı bir yaklaşım geliştirmek için sadelik ve kullanım kolaylığından dolayı olay sıra çizgeleri kullanılmaktadır.

Tanım 3. Bir olay sıra çizgesi (OSÇ) (İng. event sequence graph - ESG) (V,E) bir

yönlü çizgedir; öyle ki V ≠ ∅ sonlu bir olaylar (düğümler ya da köşeler) kümesi ve E ⊆ V×V sonlu bir yaylar (kenarlar) kümesidir. [ ve ] sırasıyla başlangıç ve bitiş olaylarını işaretlemek için kullanılan sözde olaylardır; [ olayına gelen yay ve ] olayından giden yay bulunmamaktadır [11]. n

Şekil 2 ile verilen OSÇ için, V = {[, prompt, payUSD, select, serveSoda, serveTea, cancel, returnMoney, ]} ve E = {([, prompt), (prompt, payUSD), (payUSD, select), (pa-yUSD, cancel), (select, serveSoda), (select, serveTea), (cancel, returnMoney), (serve-Soda, ]), (serveTea, ]), (returnMoney, ])}. Bu OSÇ’de prompt başlangıç olayı iken ser-veSoda, serveTea ve returnMoney bitiş olaylarıdır.

Şekil 2. Web Tabanlı Özellikli Olay Sıra Çizge Aracı [9] İçinde USD-Soda-Tea İçin Ürün

OSÇ’si [8]

Yazılım ürün hatları için özelleştirilmiş OSÇ’ler çekirdek OSÇ (ç-OSÇ) ve özellik OSÇ (ö-OSÇ) olmak üzere iki tiptir [8].

Tanım 4. Bir özellikli olay sıra çizgesi (ÖOSÇ) (İng. Featured event sequence graph

- FESG), bir çekirdek OSÇ’den (ç-OSÇ) (İng. core-ESG) ve ÜY bilgisine dayalı bir küme özellik OSÇ’den (ö-OSÇ) (İng. feature-ESG) oluşur [8]. n

Bir ç-OSÇ YÜH’ü üzerindeki tüm ürün yapılandırmalarında bulunan temel özellik-leri betimlerken ö-OSÇ’ler özellik modelindeki özelliközellik-leri betimler. Sıradan OSÇ dü-ğümlerinden ve ç-OSÇ düdü-ğümlerinden farklı olarak bir ö-OSÇ bağlantı olayları olarak

(5)

adlandırılan değişkenlik noktalarıyla ilişkilendirilmiş düğümleri içerir. Bağlantı olay-ları aslında ç-OSÇ veya diğer ö-OSÇ’lerdeki olaylardır. Bu olaylar, (OSÇ, Olay) çift-leri olarak gösterilir. Bu nedenle, bir ÖOSÇ bir OSÇ’ye dönüştürülebilir; ancak, bunun tersi ek bilgi kullanılmadan mümkün değildir. Ayrıca, bir ÖOSÇ’deki sözde olaylar ve bağlantı olayları dışındaki olayların hepsi eşsiz olarak adlandırılmalıdır.

Şekil 3’de örnek soda otomatı YÜH’ü için ç-OSÇ verilmektedir. prompt ve select olayları soda otomatı YÜH’ünün çekirdek davranışı içerisindedir ve soda otomatı YÜH’ünden üretilen tüm ürünlerde bulunmaktadır. Belirli bir YÜH ürününün davranı-şını oluşturmak için ö-OSÇ ile gösterilen seçili özelliklerin davranışları, ç-OSÇ’ye bağ-lanır. Bağlantı bilgisi ö-OSÇ’lerde saklanmaktadır [8].

Şekil 3. Soda Otomatı YÜH’ü İçin ç-OSÇ [8]

Şekil 4 soda otomatı YÜH’ünün SeveTeaBeverage özelliğinin davranışını göster-mektedir. Bu ö-OSÇ, serveTea olayının bağlanabileceği en soldaki düğümde ve en sağ-daki düğümde görülen bağlantı noktası bilgilerini içerir. Şekil 5 payUSD olayının Core_SVM ç-OSÇ’ye ve ayrıca Feature_Cancel ö-OSÇ’ye bağlanacağı soda otomatı YÜH’ünün USDPurchase özelliğinin davranışını göstermektedir. Bu bağlantılar zorun-ludur.

Şekil 4. Soda Otomatı YÜH’ünün ServeTeaBeverage Özelliğine Ait ö-OSÇ [8]

Şekil 5. Soda Otomatı YÜH’ünün USDPurchase Özelliğine Ait ö-OSÇ [8]

Bir ç-OSÇ’ye yeniden kullanımdan yararlanmak için bağlantı olayları dahil edilme-mektedir. Bununla birlikte, her ö-OSÇ bağlanacağı OSÇ’ye dair bağlantı olayları, yani değişkenlik noktaları hakkında gerekli bilgileri tutmaktadır. Ürün şemasındaki her yap-rak için bir ö-OSÇ vardır.

Bir ürüne ait bir ç-OSÇ ve bir küme ö-OSÇ birlikte ürüne ait bir ÖOSÇ’yi oluşturur. Bu model olası tüm özelliklerin üst üste bindirilmesiyle oluşturulan bir model değildir.

2.2 OSÇ’lerin Doğruluğu

Uygulamada bir model ve öğelerinin tamamıyla kullanılabilirliğini garantilemek ge-rekebilir. Aksi takdirde, bazı model öğeleri tarafından betimlenen davranışlar doğru şekilde incelenemeyebilir. Bu sebeple kullanışlılık (İng. usefulness) kavramının tanım-lanması önem taşımaktadır.

(6)

Tanım 5. G = (V, E) bir OSÇ olsun. G’ye ait e Î E olayı için eğer e olayına sözde başlangıç olayı [’dan ulaşılabiliyorsa ve e olayından sözde bitiş olayı ]’na ulaşılabili-yorsa e olayı G’de kullanışlıdır. Eğer G’deki tüm olaylar kullanışlı ise G kullanışlıdır. n

Doğru bir OSÇ (İng. valid ESG) kavramı ilk olarak Belli ve Budnik tarafından ortaya atılmıştır [12]. Bu çalışmada ise, doğru bir OSÇ modelinden kastedilen, Tanım 6’de ifade edildiği şekilde kullanışlı bir OSÇ olmasıdır. Doğru OSÇ’lerin bu şekilde tanım-lanması OSÇ modellerinin ilgili bağlamlarda etkin bir şekilde kullanılabilmesine ola-nak vermektedir. Verilen bir OSÇ’nin kullanışlı olup olmadığının denetimi farklı şekil-lerde yapılabilir. Bunlardan ikisi aşağıda örneklenmiştir:

1. OSÇ’deki her bir e olayı için [ olayından e olayına ulaşıp ulaşılmadığı ve e olayından ] olayına ulaşılıp ulaşılmadığı kontrol edilebilir.

2. [ olayından tüm olaylara ulaşılıp ulaşılmadığı ve ] olayından ters yöndeki yayları izleyerek tüm olaylara ulaşılıp ulaşılmadığı kontrol edilebilir.

İki yaklaşım da genişlik yönelimli arama algoritması benzeri bir algoritma kullanarak gerçeklenebilir. 2 numaralı yaklaşım üzerinden kullanışlılık denetimi yapan algoritma Algoritma 1’de verilmektedir.

Algoritma 1. OSÇ Kullanışlılık Denetimi

Girdi: G=(V,E) – bir OSÇ

Çıktı: true – G kullanışlı ise, false – G kullanışsız ise Q ← boş bir kuyruk yarat

F ← V’deki düğümlerle indekslenen ve tüm değerleri false olan bir boolean dizisi yarat Q’ya [’yi koy, F['['] ← true, c ← 1 //[ ile başla, [ için “ulaşıldı” işaretle, Ulaşılan düğümlerin sayısı c’yi 1 yap

while Q boş değilse do //Genişlik yönelimli olarak tüm düğümlere ulaşmaya çalış e ← Q’dan bir eleman al

for (e,x) Î E with F[x] = false do Q’ya x’i koy, F[x] ← true, c ← c + 1 endfor endwhile

if c = |V| then //Tüm düğümlere [ olayından ulaşıldı ise Q’yu ve F’yi sıfırla

Q’ya ]’yi koy, F[']'] ← true, c ← 1 //] ile başla, ] için “ulaşıldı” işaretle, Ulaşılan düğümlerin sayısı c’yi 1 yap

while Q boş değilse do //Genişlik yönelimli olarak tersten tüm düğümlere ulaşmaya çalış e ← Q’dan bir eleman al

for (x,e) Î E with F[x] = false do Q’ya x’i koy, F[x] ← true, c ← c + 1 endfor endwhile

if c = |V| then //Tüm düğümlere ] olayından tersine giderek ulaşıldı ise return true

endif endif return false

Şekil 2’de verilen OSÇ modeli doğru bir modeldir; modeldeki tüm olaylara sözde başlangıç olayından ve tüm olaylardan sözde bitiş olayına ulaşılabilmektedir. Diğer ta-raftan, Şekil 3’te verilen ç-OSÇ, Şekil 4’te verilen ö-OSÇ ve Şekil 5’te verilen ö-OSÇ

(7)

modelleri doğru OSÇ modelleri değildir. Özellikleri temsil eden bu OSÇ’lerin doğruluk denetimi izleyen bölümde açıklanmaktadır.

2.3 ÖOSÇ’lerin Doğruluğu

Kısım 2.2 sonunda örneklendiği gibi, ÖOSÇ tabanlı modellemede kullanılan ç-OSÇ ve ö-OSÇ modellerinin kullanışlı olmaması olası bir durumdur. Zira bu modeller bera-berce bir ürüne ait tam bir davranışı betimlemektedir. Bu sebeple, asıl önemli olan bu modellerin birlikte kullanışlı bir model oluşturup oluşturmadığıdır.

Yine de modellerin belli bağlamlarda kullanımı (sınama kümeleri üretme vb.) sıra-sında kolaylık sağlaması için ç-OSÇ ve ö-OSÇ modellerinin de tek başlarına kullanışlı (dolayısıyla doğru) olması faydalı olabilmektedir. Bu modelleri, kullanışlı modellere dönüştürmek amacıyla başlangıç ve bitiş işaretleme sözde olaylarının (sırasıyla [ ve ]) yanı sıra başlangıçtan kullanışlılık ve bitişten kullanışlılık sözde olayları da (sırasıyla [[ ve ]]) gerekmektedir.

[[ ve ]] olaylarının [ ve ] olayları ile beraber kullanımı aşağıdaki koşullar çerçeve-sinde olmalıdır:

1. [[ olayından önce kesinlikle [ olayı gelmelidir ve ]] olayından sonra kesinlikle ] olayı gelmelidir.

2. [[ olayından sonra gelen olaylar başlangıçtan ulaşılamayan ve kendisinden önce başka bir olay gelmeyen kullanışsız olaylar olmalıdır ve ]] olayından önce gelen olaylar kendisinden bitişe ulaşılamayan ve kendisinden sonra başka olay gelmeyen kullanışsız olaylar olmalıdır.

Şekil 6’da Şekil 3’te verilen ç-OSÇ’nin kullanışlı hali görülmektedir. ç-OSÇ içeri-sinde hali hazırda [ ve ] olayları kullanıldığından sadece [[ ve ]] doğru şekilde eklenerek model kullanışlı hale getirilmiştir. Şekil 3’te verilen ç-OSÇ’deki select olayı kullanışlı değildir; hem [ olayından bu olaya ulaşmak mümkün değildir hem de bu olaydan ] ola-yına ulaşmak mümkün değildir. Bunun mümkün hale getirmek adına OSÇ modeline {([, [[), ([[, select), (select, ]]), (]], ])} yayları eklenmiştir.

Şekil 6. Soda Otomatı YÜH’ü İçin Kullanışlı ç-OSÇ

Şekil 7’de de Şekil 5’te verilen ö-OSÇ’nin kullanışlı hali görülmektedir. ö-OSÇ’deki olayları kullanışlı hale getirmek için [[ olayı (Core_SVM, prompt) olayına bağlanmış-tır; çünkü, bu olaydan OSÇ’deki diğer tüm olaylara ulaşılabilmektedir. Ayrıca, ]] olayı (Core_SVM, select) olayına bağlanmıştır; çünkü OSÇ’deki diğer tüm olaylardan bu olaya ulaşılabilmektedir. Sonuç olarak {([, [[), ([[, (Core_SVM, prompt)), ((Core_SVM, select), ]]), (]], ])} kümesindeki yaylar OSÇ’ye eklenmiştir.

(8)

Şekil 7. Soda Otomatı YÜH’ünün USDPurchase Özelliğine Ait Kullanışlı ö-OSÇ

Bu kısmın başında bahsedildiği gibi bir ç-OSÇ ve ö-OSÇ’lerden oluşan bir ÖOSÇ’nin doğruluğu bu modellerin birlikte kullanışlı bir model oluşturup oluşturma-dığıyla ilgilidir. Bu denetimin yapılabileceği iki farklı yaklaşım aşağıda verilmektedir:

1. ÖOSÇ modeli içerisindeki ç-OSÇ ve ö-OSÇ modellerinin birleşimi ile ürüne ait bir OSÇ modeli oluşturup bu modelin kullanışlılığı Kısım 2.2’de anlatıldığı gibi kontrol edilebilir.

2. ç-OSÇ’ye ait [ olayından ÖOSÇ modelinde yer alan OSÇ’lerdeki tüm olaylara ulaşılıp ulaşılmadığı ve ç-OSÇ’ye ] olayından ters yöndeki yayları izleyerek ÖOSÇ modelinde yer alan OSÇ’lerdeki tüm olaylara ulaşılıp ulaşılmadığı kontrol edilebilir.

Algoritma 2’de 1 numaralı yaklaşım uygulanarak ÖOSÇ’ler için kullanışlılık denetimi yapan bir algoritma yer almaktadır.

Algoritma 2. ÖOSÇ Kullanışlılık Denetimi

Girdi: G=((Vc,Ec), {(Vf1,Ef1),(Vf2,Ef2),…,( Vfk,Efk)}) – Bir ç-OSÇ ve bir küme ö-OSÇ’den oluşan bir ÖOSÇ

Çıktı: true – G kullanışlı ise, false – G kullanışsız ise (V,E) ← boş bir OSÇ yarat

V ← V ∪ {[,]}

for (Vi,Ei) G’deki bir OSÇ ise do

for v Î Vi\{[,],[[,]]} and v bir bağlantı olayı değilse do V ← V ∪ {v} endfor endfor

for (Vi,Ei) G’deki bir OSÇ ise do

for (x,y) Î Ei with x Ï{[[,]] and y Ï{[[,]]} do

if x bir bağlantı olayı ise yani x = (a,b) then x' ← b else x' ← x endif if y bir bağlantı olayı ise yani y = (a,b) then y' ← b else y' ← y endif E ← E ∪ {(x',y')}

endfor endfor

z ← (V,E) OSÇ’siyle Algoritma 1’i işlet return z

3

Özellikli Olay Sıra Çizge Test Modellerinin Yönetimi

Bir yazılım ürün hattı özelliklerine ve ürünlerine ilişkin test modellerinin yönetimi aşa-ğıda verilen etkinliklerden oluşmaktadır:

• Özellikli olay sıra çizge test modellerinin oluşturulması ve güncellenmesi • Özellikli olay sıra çizge test modelinin doğrulanması

• Ürün için test modellerinin birleştirilmesi • Ürün test modelinin doğrulanması

(9)

yapılandırmalarının hazır olması gereklidir. Özellik modeline ilişkin bir örnek Şekil 1’de, ilgili ürün yapılandırmalarına ilişkin bir örnek ise Tablo 1’de verilmişti. Özellik modeli ile ürün yapılandırmalarının yönetimi de YÜH’lerde önemli bir konudur. Bu alanda en gelişmiş araçlardan biri Eclipse Modeling Framework [13] üzerinde çalışan FeatureIDE aracıdır. Bu araç 2005 yılında geliştirilmeye başlanmış [14] ve halen geliş-tirilmesi devam etmektedir [15]. Bu çalışmada da özellik modeli ve ürün yapılandırma-larının tanımlanması için FeatureIDE aracından yararlanılmıştır. FeatureIDE, özellik modelini bir XML dosyasında, ürün yapılandırmalarını ise ayrı ayrı metin dosyalarında tutmaktadır.

YÜH için özelleştirilmiş OSÇ’lerin çizilmesi, diğer bir deyişle test modellerinin oluşturulması, için web tabanlı bir uygulama geliştirilmiştir [9]. Bu web tabanlı uygu-lama, OSÇ’leri ve özelleştirilmiş OSÇ’leri JSON formatında tutmakta ve MongoDB veritabanında saklamaktadır. Bu web tabanlı uygulama, anılan test modellerinden sı-nama durumlarının üreten ve bildirinin yazarları tarafından geliştirilen bir test üretim makinası (İng. test generation engine) ile birlikte çalışmaktadır. Bu test üretim makinası hem kendi başına çalışabilecek hem de web tabanlı uygulama ile birlikte çalışabilecek şekilde tasarlanmıştır.

FeatureIDE’de üretilen özellik modeli ve ürün yapılandırmalarının test üretim ma-kinası tarafından kullanılabilmesi için XML ve metin dosyaları JSON formatına dönüş-türülmektedir. Bu sayede FeatureIDE’de üretilen özellik modeli ve ürün yapılandırma-larının tarafımızdan geliştirilen test üretim makinası tarafından tüketilmesi mümkün olmaktadır. Böylece, bir YÜH için özellik modeli ve ürün yapılandırmaları yönetimi ile test modelleri yönetimi birlikte çalışabilmektedir.

Geliştirilen web tabanlı uygulama sayesinde, test modelleri yönetiminin ilk adımı olan özellikli olay sıra çizge test modellerinin oluşturulması ve güncellenmesi etkinliği sağlanmaktadır. İkinci adım olan özellikli olay sıra çizge test modelinin doğrulanması etkinliği için Kısım 2.3’de önerilen yöntem kodlanmış ve çalışır hale getirilmiştir.

YÜH test modelleri yönetiminin üçüncü adımı olan ürün için test modellerini birleş-tirilmesi iki şekilde gerçekleştirilebilir. İlk yaklaşımda, tüm özellikler bir araya getiri-lerek ürün test modeli elde edilir. İkinci yaklaşımda ise, var olan bir ürün test modelin-den yola çıkılarak hedeflenen üründeki eksik özellikler eklenerek hedeflenen ürüne ait test modeline ulaşılır. Her iki yaklaşımı da karşılayan önerimiz [8]’de açıklanmıştır.

Ürün test modeli doğrulanması etkinliği YÜH test modelleri yönetiminin son adımı-dır. Bu etkinlik için Kısım 2.2’de önerilen yöntem kodlanmış ve çalışır hale getirilmiş-tir. Böylece, YÜH test modellerinin uçtan uca yönetimine ilişkin tüm etkinlikler için yöntem ve araç oluşturulmuştur. İzleyen kısımda bir örnek üzerinde geliştirilen kodla-rın çalıştırılması ve sonuçları irdelenmiştir.

4

Örnek Çalışma

Bu kısımda önerilen yöntemleri açıklarken kullanılan içecek otomatı örneğinden farklı olarak [8]’de gösterilen Amerikan ya da İngiliz dama ürün ailesi YÜH’ü örnek çalışma olarak kullanılacaktır. En kolay dama türü olduğu için seçilen bu YÜH’den; Çocuk daması, Amerikan daması ve İspanyol daması olmak üzere üç yazılım ürünü çıkarılması

(10)

hedeflenmiştir.

Amerikan daması 12 adet piyon ile satranç tahtasında oynanır. Bir piyon çapraz ha-reket eder ve rakibin taşının üzerine atlayarak onu ele geçirir. Piyonlar yalnızca son satıra kadar iler. Son satıra ulaştıktan sonra piyonlar vezire terfi eder ve ileri ya da geri hareket edebilir. Bir oyuncunun tüm parçaları ele geçirildiğinde oyun sona erer. İspan-yol damasında piyonların kraliçelere terfi etmesi dışında tüm kurallar aynıdır. Her iki damada da imkan varsa bir taş rakibin taşını almak zorundadır. Bu kural çocuk dama-sında bulunmamaktadır. Ayrıca, Çocuk damadama-sında bir piyon son sıraya ulaştığında oyun sona erer [8].

Amerikan dama ürün ailesi YÜH’üne ait ÖOSÇ’lerin her biri oluşturulduktan sonra özellikli olay sıra çizge test modeli doğrulanmasından geçer. Böylece, herhangi bir ürün yapılandırması sonucunda ortaya çıkacak ürüne ait test modeli OSÇ’nin özellik test modellerinden gelen bir hatayı barındırmayacağından emin olunur. Şekil 8’de çocuk daması ürününe ait OSÇ görülmektedir. Bu OSÇ, Amerikan dama ürün ailesi YÜH’üne ait ÖOSÇ’lerden bir araya getirilmiştir. Diğer ürünlere ait OSÇ’lerin düğüm ve yay sayıları Tablo 2’de verilmiştir.

Şekil 8. Çocuk Daması Ürünü OSÇ’si [8]

Tablo 2. Amerikan Dama Ürün Ailesi YÜH’üne ait OSÇ’lerin Düğüm ve Yay Sayıları [8] Düğüm Sayısı Yay Sayısı

Çocuk Daması Ürününe ait OSÇ 14 33 Amerikan Daması Ürününe ait OSÇ 31 95 İspanyol Daması Ürününe ait OSÇ 31 95

(11)

Bu bildiride önerilen ÖOSÇ’lerin doğruluğu ve OSÇ’lerin doğruluğu denetim yön-temlerinin seçilen örnek YÜH üzerinde işletilmesi sonucunda elde edilen sonuçlar Tablo 3’de ve Tablo 4’de verilmiştir. Tablo 3’de ve Tablo 4’de yer alan değerler ilgili doğruluk denetim kodların birbirinden bağımsız olarak onar defa çalıştırılmaları sonu-cunda ortaya çıkmıştır. Bu değerler Linux Ubuntu 18.04 işletim sisteminde Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz işlemcili bilgisayar üzerinde elde edilmiştir.

Tablo 3. Amerikan Dama Ürün Ailesi YÜH’üne ait ÖOSÇ’lerin Doğruluk Denetim Zamanına

İlişkin Ölçümler (milisaniye)

Asgari Azami Ortalama Çocuk Daması Ürününe ait ÖOSÇ’ler 5 6 5.2 Amerikan Daması Ürününe ait ÖOSÇ’ler 7 9 7.7 İspanyol Daması Ürününe ait ÖOSÇ’ler 7 11 8.3

Tablo 4. Amerikan Dama Ürün Ailesi YÜH’üne ait OSÇ’lerin Doğruluk Denetim Zamanına

İlişkin Ölçümler (milisaniye)

Asgari Azami Ortalama Çocuk Daması Ürününe ait OSÇ 3 5 3.8 Amerikan Daması Ürününe ait OSÇ 4 7 5.1 İspanyol Daması Ürününe ait OSÇ 4 7 5.3

5

Sonuç

Günümüzde özellikle platform temelli yazılın üretim hatlarının artması ile bu üretim hatlarında oluşturulan ürünlerin model tabanlı testleri giderek önem kazanmaktadır. Bu önemi doğrudan etkileyen süreç ise ortaya çıkan test modellerinin yönetimidir. Bu ça-lışmada YÜH’ler için test modellerinin yönetimine ilişkin bir yaklaşım önerilmiştir. Bu yaklaşımda test modellerinin yönetimi, dört ana etkinliğe bölünmüş ve her bir etkinliğe ilişkin bir çözüm öneri sunulmuştur. Bunlardan iki tanesi, bildiri yazarlarının önceki çalışmalarından alıntılanarak anlatılırken, diğer ikisi olan özellikli olay sıra çizge test modelinin doğrulanması ile ürün test modelinin doğrulanması etkinliklerine ilişkin ise bu bildiride birer yöntem önerilmiştir. Önerilen yöntemler bir örnek çalışma üzerinde çalıştırılmış ve elde edilen sonuçlar paylaşılmıştır.

Teşekkür

Bu çalışma, TÜBİTAK tarafından 117E884 numaralı “Çevik Yazılım Ürün Hatları için Olay Sıra Çizge Tabanlı Test Üretim Yöntemi Geliştirilmesi” başlıklı proje kapsa-mında desteklenmiştir, teşekkürlerimizi sunarız.

Kaynakça

1. García-Domínguez, A., Kolovos, D.S., Rose, L.M., Paige, R.F., Medina-Bulo, I.: EUnit: a unit testing framework for model management tasks. In: International Conference on Model Driven Engineering Languages and Systems. pp. 395–409. Springer (2011).

(12)

2. Van Der Straeten, R., Mens, T., Van Baelen, S.: Challenges in model-driven software engi-neering. In: International Conference on Model Driven Engineering Languages and Systems. pp. 35–47. Springer (2008).

3. Apel, S., Kästner, C.: An overview of feature-oriented software development. Journal of Ob-ject Technology. 8, 49–84 (2009).

4. Czarnecki, K.: Ulrich Eisenecker Generative Programming: Methods, Tools, and Applica-tions. Addison-Wesley, Paperback, Published June (2000).

5. Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Feature-oriented domain analysis (FODA) feasibility study. Carnegie-Mellon Univ Pittsburgh Pa Software Engineer-ing Inst (1990).

6. Thüm, T., Kästner, C., Benduhn, F., Meinicke, J., Saake, G., Leich, T.: FeatureIDE: An ex-tensible framework for feature-oriented software development. Science of Computer Pro-gramming. 79, 70–85 (2014).

7. Classen, A.: Modelling and model checking variability-intensive systems. Ph. D. dissertation (2011).

8. Tuglular, T., Beyazıt, M., Öztürk, D.: Featured Event Sequence Graphs for Model-Based In-cremental Testing of Software Product Lines. Proceedings of the 43rd International Confer-ence on Computer, Software and Applications (COMPSAC 2019), Milwaukee, Wisconsin, USA (2019).

9. Tuglular, T., Beyazıt, M., Öztürk, D., Demirci, T., Erdoğan, B.: Development of a Web-based Test Generation Tool for Agile Software Product Lines. Proceedings of the 5th Workshop on Dependability at Izmir Institute of Technology, Izmir, Turkey (2019).

10. Lochau, M., Mennicke, S., Baller, H., Ribbeck, L.: Incremental model checking of delta-oriented software product lines. Journal of Logical and Algebraic Methods in Programming. 85, 245–267 (2016).

11. Belli, F.: Finite state testing and analysis of graphical user interfaces. Proceedings of the 12th International Symposium on Software Reliability Engineering, 2001. ISSRE 2001. pp. 34– 43. IEEE, Washington, DC (2001).

12. Belli, F., Budnik, C.J.: Minimal spanning set for coverage testing of interactive systems. In-ternational Colloquium on Theoretical Aspects of Computing. pp. 220–234. Springer (2004). 13. Steinberg, D., Budinsky, F., Merks, E., Paternostro, M.: EMF: eclipse modeling framework.

Pearson Education (2008).

14. Leich, T., Apel, S., Marnitz, L., Saake, G.: Tool support for feature-oriented software devel-opment: featureIDE: an Eclipse-based approach. Proceedings of the 2005 OOPSLA work-shop on Eclipse technology eXchange. pp. 55–59. ACM (2005).

15. Meinicke, J., Thüm, T., Schröter, R., Benduhn, F., Leich, T., Saake, G.: Mastering Software Variability with FeatureIDE. Springer (2017).

Şekil

Şekil 1. FeatureIDE [6] Kullanılarak Oluşturulan İçecek Otomatı Yazılım Hattı Özellik Şeması
Tablo 1. FeatureIDE Kullanılarak Oluşturulan İçecek Otomatı Yazılım Hattı Ürün Yapılandır-
Şekil 2 ile verilen OSÇ için, V = {[, prompt, payUSD, select, serveSoda, serveTea,  cancel, returnMoney, ]} ve E = {([, prompt), (prompt, payUSD), (payUSD, select),  (pa-yUSD, cancel), (select, serveSoda), (select, serveTea), (cancel, returnMoney),  (serve
Şekil 6. Soda Otomatı YÜH’ü İçin Kullanışlı ç-OSÇ
+4

Referanslar

Benzer Belgeler

 Uygulama ve sistem yazılımlarının kimler tarafından ve ne şekilde kullanılabileceğini gösteren yazılım lisansları sözleşmeleri vardır.  Programın kurulabilmesi

M eselâ: Çok İyi mo­ dern makinelerin getirilmesi, bir sinema okulunun açılması, senaristlerimizin çok iyi bir eğitimden geçirilmesi gibi. İşte bu gibi

Cenazesi 24 Şubat 2004 Salı günü Erenköy Galip Paşa Camii’nde kılınacak öğle namazını müteakip Zincirlikuyu aile

Geleneksel yazılım test etme teknikleri açıklanmış ve sistem seviyesinde uygulanabilecek performans testi, yükleme testi, birim testi ve kara kutu test

Nesneye yönelimli programlamada ortalama çevrimsel karmaşıklık hesaplanırken sınıf içinde bulunan metotların çevrimsel karmaşıklığı toplanır ve metot

Bilişim firmalarının üretmiş oldukları yazılımlar her geçen gün işletmelerin ve bireysel kullanıcıların hayatını kolaylaştırmaktadır. Bu nedenle piyasa ihtiyacına

Anahtar Sözcükler: Mobil Cihazlar, Akıllı telefon, yazılım telefonu, Android, VoIP, SIP, Sayısal Santral.. Enterprise Soft Phone Prototoype Development Process: Analysis and

Bu çalışmada ASELSAN Savunma Sistem Teknolojileri Sektör Başkanlığı bünyesindeki Komuta Kontrol Yazılım Tasarım Bölümü’nde yürütülen ve Teknik Ateş