Bile³en Modellerinde De§i³kenlik Yönetimi Yakla³mlarnn ncelenmesi 1 1 1,2 Muhammed Ça§r Kaya , Alper Karamanlo§lu , Mahdi Saeedi Nikoo , Sina 1 3 1 Entekhabi , Selma Sülo§lu , Ali H. Do§ru Orta Do§u Teknik Üniversitesi, 1 Ankara, Türkiye {mckaya,alperk,entekhabi,dogru}@ceng.metu.edu.tr 2 Spark Kalibrasyon Hizmetleri, Ankara, Türkiye mahdi_saeedi@sparkkalibrasyon.com.tr 3 Sosoft Bili³im Teknolojileri, Ankara, Türkiye selma@sosoft.com.tr Özet Bu çal³mada daha önce bile³en modelleri üzerine yaplm³ bir ya- zn taramas çal³masnn sonucunda ortaya çkan modellerde de§i³kenlik yönetimi kabiliyeti ara³trlmaktadr. Yazarlar tarafndan bu do§rultuda kapsaml bir `Sistematik Yazn Taramas' (SLR) çal³mas yaplmakta- dr, bu çal³mann ara bulgular olarak da faydal bilgiler ortaya çkm³- tr ve bu bilgiler ön de§erlendirmeler olarak bu makalede sunulmaktadr. 24 bile³en modeli üzerinde çal³ma yaplm³ ve genelde bu modellerde de§i³kenlik yönetiminin yeterince desteklenmedi§i gözlemlenmi³tir. Ma- kale, bile³en modeli de§erlendirmelerini sunduktan sonra de§i³kenlik ko- nusunda baz önerileri de dile getirmektedir. Anahtar Kelimeler: bile³en modeli, de§i³kenlik modeli, de§i³kenlik yönetimi, yazlm bile³eni 1 Giri³ Günümüzde tekrar kullanlabilir bile³enleri biraraya getirerek olu³turulan sis- temlerin says gittikçe artmaktadr. Yazlm bile³enleri daha kompleks sistemleri olu³turmak üzere bir araya getirilen yap ta³lardr. Bu karma³k ve büyük çapl sistemleri gerçekle³tirmek için çok sayda bile³en modeli önerilmi³tir. Ancak bu yakla³mlarn ba³arl saylmalar için sistematik bir tekrar kullanm destekle- meleri, kabul edilebilir bir sürede tamamlamay sa§lamas ve kalite isterlerini kar³lamalar beklenmektedir. Bile³en tabanl bir sistemin geli³tirme sürecinde tekrar kullanm desteklemek için hem ortak parçalarn hem de de§i³ken parça- larn do§ru ifade edilmesi gerekir [1]. Di§er taraftan, yazlm ürün hatlarnda yaygnca faydalanlan ortaklk ve de- §i³kenlik (commonality and variability) kavramlarnn modellemesinin ne derece 502 etkin oldu§u bilinmektedir. De§i³kenli§in etkin bir ³ekilde yönetilmesi sonucunda yeniden kullanm yönelimli verimlili§in en yüksek düzeylerde ve kurumsal bir ta- banda planlandrlm³ olarak elde edilmesi hedeenebilir. De§i³kenlik, yazlm ürün hatlarnda oldu§u gibi, verimli bile³imsel sistemler elde etmek için kullanlmas gereken önemli bir kavramdr. Ortaklk ve de§i³- kenlik yazlm ürün hatlarnn kavramsal temelini olu³turmaktadr. Alan modeli belirli bir olgunlu§a ula³t§nda, ürün mühendisli§i için ortaklk kavramn kul- lanmak daha az çaba gerektirir. Ancak ürünün belirtilmesi ve in³asna do§ru de§i³kenlik çok önemli bir yere sahip olur. Ürün mühendisli§inin verimlili§ini etkileyen en önemli faktörlerden biri ba§lanma zamanlarn göz önüne alarak de§i³kenli§i yönetebilmektir [2]. Bile³enler, sa§ladklar tekrar kullanm teknolojisiyle yazlm geli³tirmenin önemli bir unsuru haline gelmi³lerdir. Bu çal³ma temel olarak bile³en tabanl yazlm geli³tirmede de§i³kenli§in kullanmn ara³trmaktadr. De§i³kenlik kul- lanmn yaygnla³trmak ve ilerletmek için öncelikle var olan yakla³mlarn in- celenmesi gerekir. Bu nedenle bu çal³mada öncelikle çe³itli bile³en modelleri için de§i³kenli§in ele alnma durumu ara³trlm³tr. Uzun vadede hedef, bile³en tabanl yakla³mlarda etkin de§i³kenlik yönetimi sa§layacak kabiliyetlerin geli³- tirilmesidir. Crnkovic vd. tarafndan yaplan literatür çal³masnda [3] bir bile³en mode- linin tanmlamas yaplm³ ve var olan yakla³mlardan bu tanmlamaya uyan 24 model oldu§u belirtilmi³tir. Ele alnan modeller ve snandrma kriterlerine göre modellerin kar³la³trma tablolarna [3]'ten ula³labilir. Bu çal³mada [3]'teki bile³en modelleri referans alnm³ ve hangilerinin de§i³kenli§i destekledi§i ara³- trlm³tr. De§i³kenlik deste§i olan modellerin hangi yakla³mlarla modelleme yaptklar incelenmi³tir. Referans çal³ma [3], inceledi§imiz kadaryla bile³en modellerini snayan en güncel çal³madr. Çal³mamzda, referans çal³mann yaynland§ tarihten sonra önerilen bile³en modellerinin, yine belirtilen snandrma kriterlerine uygunlu§u ba³ka bir çal³ma konusu olarak de§erlendirilmi³ ve mevcut bile³en modellerinin de§i³kenlik destekleri ara³trlm³tr. 2 De§i³kenlik Yazlm ürün hatlarnn kullanm için önerilen Nitelik Modeli (Feature Model) kavram, Kang [4] tarafndan ortaya atlm³ ve ksa zamanda bu modellerin daha kapsaml versiyonlar geli³tirilmi³tir. Farkl endüstri alanlarnda yaygnca uygu- lama alan bulan yazlm ürün hatlar ve dolays ile Nitelik Modelleri, de§i³kenlik modellemesi konusunda bir öncü olarak ortaya çkm³tr. Nitelik modelleri içe- risinde örgün olarak modellenen de§i³kenlik, ciddi projelerde çok ksa zamanda hem nitelik modelinin fazlaca büyümesi ve karma³kla³mas hem de de§i³ken- li§in bu karma³klk içerisinde ve ayrca kendi karma³kl§ ile ele alnmasnn zorluklarn ortaya koymu³tur. Bu gözlemin sonucu olarak de§i³kenli§i ayrca modelleyen yakla³mlar belirmi³tir. 503 De§i³kenlik modellemesi konusunda öncü kabul edilebilecek iki yakla³m ola- rak OVM [5] ve Covamof 'tan [6] söz edilebilir. Nitelik modelleri de örgün olarak kapsaml bir de§i³kenlik modeli içermektedir. Daha sonra birkaç hatr saylr de§i³kenlik modeli de ortaya çkm³tr, ancak halen en çok bu iki model kulla- nlmaktadr. De§i³kenlik modellerinde aranan nitelikler olarak: 1. Kendi ba³na ayr bir model olmas, 2. Ba§lanma zamannn (örne§in tasarm, derleme, yükleme gibi zamanlarnda de§i³kenli§in çözümlenmesi) yönetilebilmesi, 3. D³ ve iç de§i³kenli§in modellenebilmesi, 4. De§i³kenlikler arasnda kstlarn tanmlanabilmesi ve 5. Hiyerar³ik de§i³kenlik modellemesi ve de§i³kenlik çözümlenmesinin (müm- künse otomatik) yaylm ortaya çkmaktadr. De§i³kenli§i modellerken tipik olarak de§i³kenlik noktalar (variation points) ve bu noktalarda sunulacak seçenekler (variants) ele alnmaktadr. Ayrca, nite- lik modellerinde bulunan kst ba§lantlar da de§i³kenlikleri içererek daha ge- ni³letilmi³ bir çerçevede ele alnmaldr. Bir de§i³kenlik noktasnda yaplacak bir tercihin, sistemin farkl noktalarnda hangi seçeneklerin içerilme veya yasaklan- masna neden olaca§ model tarafndan desteklenmelidir. 3 Bile³en Tabanl Yazlm Geli³tirme Bile³en tabanl yakla³mlar, yeniden kullanlabilir yap ta³lar, yani bile³enlerin kullanlmas ile karma³k ve büyük ölçekli yazlm sistemlerinin gerçekle³meleri için kullanlmaktadr. Bile³en Tabanl Yazlm Mühendisli§i (CBSE), ba§msz bile³enlerin kullanlmas ile gev³ek ba§l sistemleri tanmlama, modelleme ve uy- gulama konularnda süreçler ve metodolojiler sunmaktadr. 1990'lardan itibaren, Bile³en Tabanl Yazlm Geli³tirme (CBSD) yakla³mnn temel kri, önceden olu³turulmu³ yazlm bile³enlerini entegre ederek büyük sistemlerin in³a edilmesi olmu³tur. Bile³enler, uygulama ayrntlarn gizleyebilirken i³levlerini ve davra- n³larn gösterir arayüzler sunmaktadrlar. Belirtilen arayüzlerin kullanlmas ile bile³enler bile üçüncü parti bile³enlerin tümle³tirilmesi yoluyla daha kolayca ku- rumlandrlabilir. Bile³en teknolojileri farkl platformlarda olgunla³rken ilk göze çarpan sunumlar Szypersky [7] tarafndan yaynlanan bir kitapla 1995 ylnda yazlm geli³tiricilerin dikkatine sunulmu³tur. Bile³enlerin yalnzca bir teknoloji de§il, temel bir yönelim kavram olarak da ele alnmas önerilmi³tir [8]. Nesne yö- neliminde nasl gereksinimler düzeyinden ba³lanarak her kavram nesne snar ile modelleniyorsa, bile³ene yönelik bir yakla³mda da soyut ve somut düzeyleri de kapsamak üzere her kavram bile³enlerle modelleme kri öne atlm³tr. Bi- le³en teknolojileri, kod yazmadan geli³tirme yapma paradigmasn destekleyen teknolojiler olarak ele alnm³tr. Bu yakla³m, problem tanmnn elde edilmesi- nin hemen ardndan problemin alt parçalarnn, `soyut bile³enler' modellenerek bir çözüm temsili ile e³lenmeleri ve daha sonra bu soyut bile³enlerin mevcut bi- le³enlerle gerçeklenmelerini önermektedir. Soyut tanmlar ile mevcut bile³enler 504 arasndaki uyumsuzluklar ise modeldeki ayr³trma ve son çare olarak da bile- ³en uyarlama/geli³tirme etkinlikleri ile çözümlenmelidir. Yazlm sistemleri için talep geli³ti§i sürece büyük boyutta ve daha karma³k gereksinimlerin yeniden kullanlabilirlik ve bile³en yönetimi ile kar³lanmas gittikçe kaçnlmaz hale gel- mektedir. 4 Mevcut Bile³en Modellerine Bak³ Bile³en modelleri, tümle³ik birle³tirme ortamlarnca desteklenmek üzere farkl araç üreticileri tarafndan ve ara³trmaclar tarafndan önerilmi³tir. Önceleri iki üç de§i³ik modelden söz edilmi³ ve hala bu modellerin etkinli§i devam etmekte ise de zamanla fazla sayda bile³en modeli ortaya çkm³tr ve bu say hala art- maktadr. Di§er taraftan, nitelik modellerinin kullanlmaya ba³lamasnn ardn- dan farkl de§i³kenlik modelleri de üretilmektedir. Bile³en modelleri, UML gibi standartla³m³ modelleme araçlarn da etkilemi³tir. Örne§in arayüz türlerinin tanmlanmas önce bile³en modellerinde sonra UML'de ayn sembolleri kulla- narak gerçekle³tirilmi³tir. UML araçlar, kendilerini `nesneye yönelik' olmann yansra, `bile³en tabanl' olarak da tantabilmektedirler. Bu tantmn anlam, esas olarak nesne kavram yönelimi ile modeller geli³tirilmekte, ancak baz alt problemler için hazr çözümlere mimari tasarmda yer verilebilmesidir. Farkl so- yutlama düzeylerini ele alan, farkl kapsaml bile³en modelleme yakla³mlar ve bunlar destekleyen araçlar bulunmaktadr. Temel hedeerini göz önüne alarak, bir modelden yola çkld§nda gerekecek bile³enlerin bulunup uyarlanp birle³ti- rilmesi admlarnn araçlar ile desteklenmesi önemli olmaktadr. Bile³enler yap- lar açsndan belirli bir uygulama sahasna yöneliktirler. Bu konuda en erken ve ba³arl bir örnek, Graksel Arayüz Tasarm alandr. Ço§u geli³tirme ortam, kaydrma çubu§u, ana menü, dü§me gibi standart ekran elemanlarn bile³enler olarak sunmu³lardr. Dolays ile önceleri çok vakit alan kullanc arayüzü geli³- tirme i³lemleri artk kod yazmadan yaplabilmektedir. Önceleri platform düze- yinde çözümler aranan bile³en teknolo jileri, günümüzde farkl uygulama sahasna özel olarak ba³ar göstermektedirler. Örne§in AUTOSAR [9], otomotiv alannda bile³en tabanl tasarm yapmak için yaygnca kullanlan bir bile³en modelidir. Bile³en modellerinin önemli baz özelliklerini a³a§daki gibi özetlemek mümkün- dür:  Kapsadklar soyutlama düzeyleri,  Gerçekle³tirme deste§i verecek araçlarn bulunmas,  Uygulama alan ve  De§i³kenlik yönetimi. Referans makalemiz [3]'te listelenen bile³en modellerinden AUTOSAR ve KobrA [10] farkl düzeylerde de§i³kenlik yakla³mlar içermektedir. Bölüm 4.1 ve 4.2'de srasyla bu modellerdeki yakla³mlara ksaca de§inilmi³tir. Di§er mo- dellerde de§i³kenlik yönetimi ile ilgili beklentileri kar³layacak düzeyde bir mo- delleme deste§i oldu§u gözlemlenmemi³tir. Ancak baz modellerin de§i³kenli§e 505 benzer yakla³mlar vardr. Bunlara bölüm 4.3'te de§inilmi³tir. Referans makale- mizde yer alan ancak bu çal³mada ad geçmeyen di§er bile³en modellerinde ise de§i³kenlik yakla³m ya da benzer bir yakla³m saptanmam³tr. 4.1 AUTOSAR De§i³kenli§i AUTOSAR otomotiv alanndaki gömülü sistemlerde kullanlmak üzere geli³ti- rilmi³tir. Temel amac ortamdan ba§msz ve ta³nabilir yazlm bile³enleri olu³- turmaktr. AUTOSAR'n hiçbir sürümünde tam anlamyla de§i³kenlik yönetimi desteklenmemi³tir. Ancak 4.0 sürümünden sonra de§i³kenli§i kullanan bir yak- la³m getirilmi³tir. 4.0'dan önceki baz sürümlerde (3.x) model elemanlarna ek bilgiler eklenerek ve araca özel olmak üzere de§i³kenlik kullanlabilir [11]. 4.0 ve sonraki sürümlerde de§i³kenlik kullanm nitelik modelleriyle kstl da olsa tanmlanm³tr. Bu kstlara örnek olarak elemanlar aras ba§llklarn gösterile- memesi verilebilir. 4.0 sürümünde dahi metamodelde de§i³kenlik yönetimi dü³ü- nülmemi³tir. Ancak d³ardan kullanlacak pure::variants [12] gibi baz araçlarla de§i³kenlik yönetilebilir. 4.2 KobrA De§i³kenli§i KobrA bile³en tabanl geli³tirme için kullanlan model güdümlü (model-driven) bir yakla³mdr. KobrA bile³en modeli UML modelini karar modeli ile birle³ti- rerek bile³en de§i³kenli§ini tanmlamaktadr. Bir karar modeli en az bir hare- ket aksiyomu içeren formel bir sistemdir. KobrA'da genel de§i³kenlik modelinin gösterimi uygulamadan ba§mszdr ve en uygun geli³tirme metodunun seçile- bilmesi mümkün olmaktadr. Her bir de§i³kenlik noktas bir karara ba§ldr ve her bile³en yapsal, davran³sal ve fonksiyonel modelin d³nda karar modeli ile ili³kilendirilmektedir. Burada tanmlanan de§i³kenlik yönetimi yaz tabanldr. Bu da de§i³kenlik yönetimini kimi zaman araç deste§ine ra§men karma³k hale getirebilmektedir. 4.3 Di§er Modellerde De§i³kenlik OSGi [13], bile³en-tabanl geli³tirim için tekrar kullanlabilirli§i sa§layan dina- mik ve modüler bir mimari sunan bir yakla³mdr. Geli³tirilmi³ olan paket ve snarn zaman içinde de§i³imini ve yenilerinin sisteme dahil edilebilmesini ko- laylkla yönetebilmek için `yazlm y§n' (bundle) ad verilen bir modül yaps tanmlam³tr. Yazlm y§nlar arayüzlerinde kendi özelliklerini, d³arya ver- di§i servisleri, d³ardan istedi§i ve ba§ml oldu§u servisleri tanmlar. OSGi'nin güçlü yan ise çal³an uygulama durdurulmadan dinamik olarak yazlm y§n- larnn ekleme, çkarma, yükleme ve kaldrma i³lemlerine olanak sa§lamasdr. Ancak OSGi ile entegre çal³an ayr bir de§i³kenlik modeli bulunmamaktadr [14]. Fractal [15], sistemlerin ve uygulamalarn tasarm, hayata geçirilmesi, da- §tm ve yeniden yaplandrlmasn sa§layan modüler, geni³letilebilir ve prog- ramlama dillerinden ba§msz bir bile³en modelidir. Fractal modeli bile³enlerin 506 dinamik olarak yeniden yaplandrlmasn destekler. Her bir Fractal bile³eni, bi- le³enin yeniden yaplandrlmasn kontrol etmek için `membrane' ad verilen bir konteyner bulundurmaktadr. Ayrca ROBOCOP [16], OpenCOM [17] ve SOFA 2.0 [18] bile³en modellerinde de farkl ³ekillerde dinamik yeniden yaplandrma desteklenmektedir. Genel olarak endüstriyel otomasyon alannda kullanlan IEC 61499 [19] mo- delinde, dü³ük soyutlama seviyesinde fonksiyon bloklarnn girdileri de§i³tirilerek yeniden yaplandrma sa§lanabilmektedir. Ancak bu yeniden yaplandrma uy- gulama seviyesinde desteklenmemektedir [20]. Koala elektronik alanndaki gömülü sistemlerde kullanlmak üzere geli³tirilen bir bile³en modeli ve mimari tanmlama dilidir [21]. Temel amac yazlmlarn ar- tan karma³kl§n ve çe³itlili§ini (diversity) yönetebilmektir. Koala'da bile³enle- rin yapsal farkll§n yönetmek için özel bir anahtar ba§layc (switch connector) bulunmaktadr. Burada belirtilen anahtar ba§layc, girilen veriye ba§l olarak birden fazla ba§lantdan birini seçebilme özelli§ine sahiptir. Bu özel mekanizma mod de§i³imini (mode switch) sa§lamaktadr. SaveCCM [22] araç kontrol sistemlerinde kullanlmak üzere geli³tirilen bir bile³en modelidir. Koala'da kullanlan anahtar ba§laycnn ayns bu modelde de kullanlmaktadr. BlueArX bile³en modeli [23] donanm maliyeti nedeniyle snrl kaynaklara sahip otomotiv alanlar için geli³tirilmi³tir. Bu model kendi yazlm bile³enleri tarafndan üretilen çoklu mod (mode) uygulamalarn destekler. Mod, anlamsal içerik bilgisinin bir türü olarak kabul edilmektedir. Farkl modlar farkl kontrol stratejilerini ifade eder. Bu modelde çoklu mod sistemi tamamen in³a edilmeden BlueArX bile³eninin modu açkça tanmlanmamaktadr [24]. Rubus [25] kara ta³tlarnda bulunan gömülü kontrol sistemleri için geli³tiril- mi³tir. Rubus'ta mod sistemin bir özelli§i olarak kabul edilir. Bile³enlerin sabit yaplandrlmas her bir mod için sistem genelinde olmaktadr. COMDES-II [26] modeli ise gerçek zamanl kstlamalara sahip da§tk gömülü kontrol sistemleri için bir bile³en tabanl yazlm çerçevesi tanmlamaktadr. COMDES-II farkl modlarda bile³en yaplandrlmasn sa§lamak için bir durum makinesi kullan- maktadr [27]. 4.4 Gözlemler Ele alnan bile³en modellerinde yazlm üretim hatlarnda ula³lm³ bulunan ol- gunluk seviyesine yakn bir de§i³kenlik modellemesi bulunmamaktadr. Ço§u bi- le³en modelinde de§i³kenlik ele alnmam³ken, bir ksmnda bile³en tümle³tirme- sinin do§al bir adm olarak ortaya çkan bile³en de§i³tirme (tak/çkar) admnn dolayl olarak de§i³kenlik konusunu destekledi§i görünmektedir. Ancak bu dü- zeydeki bir destek, ayr bir de§i³kenlik modelinden olan beklentileri kar³lamak için yeterli de§ildir. Ço§u bile³en modelinin soyut düzeylerden çok kod düzeyinde araçlar ve modelleme mekanizmalar ile desteklendi§ini söylemek yanl³ olmaz. Karma³kl§ yönetmek üzere soyut düzeylerden ba³layacak bir modeldense, ks- men tasarmnn mevcut oldu§u varsaylan bir sistemin kod parçalarnn hzl bir 507 ³ekilde bulunup birle³tirilmesi öne çkm³ gibidir. Ula³lm³ olan sonuçlar ksaca sunacak olursak: 1. Ayrk bir de§i³kenlik modeli ile desteklenme kabiliyeti yok denecek kadar azdr. 2. De§i³kenlik daha çok tümle³tirme düzeyinde ve minimal model soyutlamas ile ele alnmaktadr. 3. De§i³kenlikler aras kst yaylm çözümlemesi eksiktir. 4. Farkl modeller aras birlikte çal³abilirlik, modellerin kod düzeyine verdikleri önem sonucunda kaybedilen soyutlama ile birlikte zayftr. 5. Alana yönelik modellerde de§i³kenlikler daha anlaml olarak modellenebi- lecek temellere sahiptir. 5 Öneriler Ara³trmada bile³en modelleri için de§i³kenlik deste§inin yeteri kadar detayl ve kavranabilir olmad§ sonucuna varlm³tr. A³a§daki problemler hala çözüm beklemektedir:  De§i³kenlik kolay yönetilebilirlik için i³lerin ayrlmas prensibine uygun ola- rak açk ve ayr bir model olarak ele alnmaldr [28]. Nitelik modelleri prob- lem uzayyla iç içedir ve çözüm uzayndaki gereksinimleri kar³lamaktan uzaktr. De§i³kenlik noktalar, de§i³kenler, bunlarn arasndaki ili³kiler ve bile³en tabanl yazlm unsurlaryla e³le³tirilmeleri di§er i³lerden ayr yapl- maldr.  De§i³kenlik geli³tirimden analiz ve test düzeyine kadar tüm yazlm geli³- tirme süreçlerinde yönetilebilmelidir. Yazlm do§rulamas genellikle nitelik modeli seviyesinde uygulanmaktadr. Ancak bile³en modellerinin tutarll§ tasarm a³amasnda kontrol edilmelidir.  De§i³kenlik, sistemin gerçek davran³n belirleyecek olan bile³en tümle³tiril- mesine de uygulanabilir olmaldr.  Çal³trlabilir bir sistem için bile³enlerin yannda bir süreç modeli de gerekir ve de§i³kenlik yönetimi bu iki farkl dünyay (bile³enler ve süreçler) tutarl bir ³ekilde desteklemelidir.  De§i³kenlik hiyerar³ik olarak yukardan a³a§ya olabildi§ince otomatik bir ³ekilde çözümlenebilmelidir [6].  De§i³kenlik; modeldeki bile³en, ba§layc, arayüz ve birle³im unsurlarnn tümüne uygulanabilmelidir. Bu öneriler göz önünde bulundurularak a³a§daki gibi bir çözüm teklif edil- mektedir: Önceki çal³malarmzdan [29]'da COSEML dili (Component Oriented Soft- ware Engineering Modeling Language) de§i³kenlik yönetimi yakla³myla geni³- letilmi³tir. Olu³turulan yeni dilde (XCOSEML), COSEML'deki statik unsurlarn yanna; `dinamik unsurlar', `de§i³kenlik unsurlar', statik ve dinamik unsurlarla 508 de§i³kenlik unsurlarn e³leyen `e³le³tirme unsurlar' eklenmi³tir. XCOSEML me- tamodeli, i³lerin ayrlmas prensibine sadk kalnarak 3 ana parçadan olu³turul- mu³tur. Bu parçalar; `COSEML belirtimi' (COSEML Specication), `e³le³tirme belirtimi' (Mapping between COSEML and Varibility Specications), ve `de§i³- kenlik belirtimidir' (Variability Specication). “ekil 1'de metamodele genel bir bak³ gösterilmektedir. “ekil 2 metamodelin COSEML belirtimi parçasn gös- terirken, “ekil 3'te e³le³tirme ve de§i³kenlik belirtimleri beraber gösterilmi³tir. Metamodelin detayl anlatm ve XCOSEML diliyle olu³turulan örnek sistemlere [29][30][31] çal³malarndan ula³labilir. “ekil 1. XCOSEML metamodeline genel bak³. Yazlm do§rulamas prensibine uymak için ise metamodele dayanarak olu³- turulan XCOSEML modelleri için do§rulama çal³mas yaplm³tr. Modeller dil dönü³ümüyle bir model denetleme aracnn girdisine uygun hale getirilerek çal- ³abilirlikleri kontrol edilmi³tir [30][31]. XCOSEML dilinde, öncüsü COSEML'de oldu§u gibi ba§layclar (connector) birinci snf unsur olarak ele alnm³ ve modellemeye dahil edilmi³tir. Buna kar- ³n ba§layc tanmlamas soyut seviyede kalm³ ve de§i³kenlik unsurlar ba§la- yclara uygulanmam³tr. Bu çal³mamzda XCOSEML dilindeki ba§layclarn de§i³kenlik unsurlaryla e³le³tirilmesi metamodel seviyesinde gösterilmektedir. Ba§layc ve çevre unsurlarla olan ba§lantlar “ekil 2'nin `sabit bak³' (Static View) ksmnda görülebilir. Ba§layclar; verimlilik, karma³klk, geni³letilebilirlik gibi i³lev-d³ özellik- ler ba³ta olmak üzere sistemin karakteristi§ini belirlemede önemli rol oynar. Bu nedenle yazlm sistemine en uygun ba§laycnn seçilmesi, ya da mevcut ba§layclarn istenen ³ekilde düzenlenebilmesi önem kazanr. Ortam (context) özelliklerinin ve sistemde kullanlan bile³enlerin ba§layc seçimini ya da ba§la- yclarn içeri§ini kstlamas da söz konusudur. Bu konular göz önüne alnarak XCOSEML metamodelinde a³a§daki geni³letmeler yaplm³tr:  XCOSEML'de içeri§i tanmlanmam³ olan ba§layc (Connector) kutusu, Mehta vd. tarafndan yaplan ba§layc snandrma çal³masndaki [32] 4 temel ba§layc görevini (Ba§lant (Communication), Düzenleme (Coordina- tion), Dönü³türme (Conversion), Kolayla³trma (Facilitation)) tanmlamak üzere arayüzle (Interface) ba§lanm³tr. De§i³kenlik unsurlaryla ba§l olan arayüz sayesinde ba§laycnn, sa§lad§ etkile³im hizmetleri için, farkl ara- 509 yüzlere sahip olmas sa§lanacak ya da bir arayüz aracl§yla gösterilen hiz- metlerinin geli³tirici tarafndan seçilmesine imkan tannacaktr.  Üst seviyede ba§lanan bir de§i³kenlik noktasnn ba§layc üzerinde olan etki- lerinin gösterilmesi de§i³kenlik e³le³tirmesi (Variability Mapping) kutusuyla olan ba§lantyla ifade edilmektedir.  Ortam ifade eden baz de§i³kenlerin (örne§in ortam scakl§, donanm özel- likleri vb.) ba§layclarn i³levini etkileme durumu söz konusudur. Bu durum ba§layc ile ortam parametreleri (Context Parameters) kutusunun ba§lan- masyla ifade edilmi³tir. “ekil 2. XCOSEML metamodel - COSEML belirtimi. COSEML belirtimi d³nda kalan kutular, E³leme Belirtimi ksmnda yer almaktadrlar. 510 “ekil 3. XCOSEML metamodel - E³le³tirme ve de§i³kenlik belirtimleri ([29]'dan uyar- lanm³tr). 6 Sonuç Yaplmakta olan sistematik yazn taramas çal³masnn bir ara evresinde bi- le³enlerde de§i³kenlik modellemesi ile ilgili önemli gözlemlerde bulunulmu³ ve bu konudaki yakla³mlar ksmen iyile³tirme önerileri ile desteklenmi³tir. Yazar- lar daha önce nitelik modelleri ve Servis Yönelimli Mimari platformlarnda da, burada sunulan öneriler ile ilgili durum çal³malar yapm³ olup [33] benzeri çözümlerin bile³en modellerine de ta³nabilece§i umulmaktadr. Bir taraftan ge- lece§e yönelik olarak kapsaml yazn taramas devam etmekte ve yaknda daha ayrntl sonuçlara ula³laca§ varsaylmaktadr. Bu çal³mann sonrasnda da ilk de§erlendirme kümesinde bulunan bile³en modellerini a³arak benzeri bir çal³ma, geli³mekte olan bile³en modellerine de geni³letilebilir. 511 Kaynaklar 1. Kim S. D., Her J. S., Chang S. H.: A theoretical foundation of variability in component-based development. Information and Software Technology, Volume 47, Issue 10, 663673 (2005) 2. Gurp J. V., Bosch J., Svahnberg M.: On the Notion of Variability in Software Product Lines. In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA '01). IEEE Computer Society, Washington, DC, USA (2001) 3. Crnkovic I., Sentilles S., Vulgarakis A., Chaudron M. R. V.: A Classication Frame- work for Software Component Models. IEEE Transactions on Software Engineering. 37, 593615 (2011) 4. Kang K. C., Kim S., Lee J., Kim K., Shin E., Huh M.: FORM: A feature-oriented reuse method with domain-specic reference architectures. Ann. Softw. Eng. 5, 143 168 (1998) 5. Pohl, K., Böckle, G., van Der Linden, F. J.: Software product line engineering: foundations, principles and techniques. Springer Science and Business Media (2005) 6. Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J.: Covamof: A framework for modeling variability in software product families. In Software product lines, Springer, 197213 (2004) 7. Szyperski, C.: Component software: beyond object-oriented programming. Harlow, Engl. Addison-Wesley (1995) 8. Dogru, A. H., Tanik, M. M.: A process model for component-oriented software engineering. IEEE Softw. 20, 3441 (2003) 9. AUTOSAR (AUTomotive Open System ARchitecture), https://www.autosar.org 10. Atkinson, C.: Component-based product line engineering with UML. Pearson Edu- cation (2002) 11. Schulze, M., Weiland, J., Beuche, D.: Automotive model-driven development and the challenge of variability. In: Proceedings of the 16th International Software Pro- duct Line Conference-Volume 1, pp. 207214 (2012) 12. pure-systems GmbH: pure::variants Eclipse Plugin User Guide, (2011) 13. OSGi Alliance, "OSGi Service Platform Core Specication, V4.1," (2007) 14. OSGi Alliance, https://www.osgi.org/ 15. E. Bruneton, T. Coupaye, J. Stefani,: The Fractal Component Model Specica- tion, The ObjectWeb Consortium, technical report, http://fractal.objectweb. org/specification/index. (2004) 16. Maaskant H.: A Robust Component Model for Consumer Electronic Products. vol. 3, Springer, 167192 (2005) 17. Clarke M., Blair G., Coulson G., Parlavantzas N.: An Ecient Component Mo- del for the Construction of Adaptive Middleware. In: Proc. IFIP/ACM Int'l Conf. Distributed Systems Platforms. (2001) 18. Bures T., Hnetynka P., Pla'sil F.: SOFA 2.0: Balancing Advanced Features in a Hierarchical Component Model. In: Proc. Int'l Conf. Software Eng. Research, Management and Applications, 4048 (2006) 19. Vyatkin V., Instrument Society of America: IEC 61499 function blocks for em- bedded and distributed control systems design. ISA-Instrumentation, Systems, and Automation Society, (2007) 20. Froschauer R., Dhungana D., Gruenbacher P.: Managing the Life-cycle of Industrial Automation Systems with Product Line Variability Models. In: 34th Euromicro Conference Software Engineering and Advanced Applications, Parma, 3542 (2008) 512 21. Van Ommering, R., Van Der Linden, F., Kramer, J. Magee, J.: The Koala compo- nent model for consumer electronics software. Computer (Long. Beach. Calif). 33, 78-85 (2000) 22. M. Akerholm, J. Carlson, J. Fredriksson, H. Hansson, J. Hakansson, A. Moller, P. Pettersson, and M. Tivoli: The SAVE Approach to Component-Based Development of Vehicular Systems. J. Systems and Software, vol. 80, no. 5, 655-667 (2007) 23. Kim J.E., Rogalla O., Kramer S., A. Haman: Extracting, Specifying and Predicting Software System Properties in Component Based Real-Time Embedded Software Development. In: Proc. 31st Int'l Conf. Software Eng. (2009) 24. Hang Y.: Introducing Mode Switch in Component-Based Software Development. (2015) 25. Hanninen K., Maki-Turja J., Nolin M., Lindberg M., Lundback J., Lundback K.: The Rubus Component Model for Resource Constrained Real-Time Systems. In: Proc. Int'l Symp. Industrial Embedded Systems. 177-183 (2008) 26. Ke X., Sierszecki K., Angelov C.: COMDES-II: A Component-Based Framework for Generative Development of Distributed Real-Time Control Systems. In: Proc. 13th IEEE Int'l Conf. Embedded and Real-Time Computing Systems and Applications. 199-208 (2007) 27. Hang Y., Hongwan Q., Jan C., Hans H.: Mode switch handling for the ProCom component model. In: Proceedings of the 16th International ACM Sigsoft sympo- sium on Component-based software engineering. ACM, (2013) 28. Metzger A., Pohl K., Heymans P., Schobbens P. Y., Saval G.: Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis. In: 15th IEEE International Requirements Engineering Conference (RE 2007), Delhi. 243253 (2007) 29. Kaya M. C., Suloglu S., Dogru A. H.: Variability Modeling in Component Oriented System Engineering. In: The 19th International Conference on Transformative Sci- ence and Engineering, Business and Social Innovation, Kuching, Sarawak, Malaysia. (2014) 30. Kaya. M. Ç., Modeling Variability in Component Oriented Software Engineering. MSc Thesis, Middle East Techical University. (2015) 31. Kaya M. C., Saeedi Nikoo M., Suloglu S., Dogru A. H.: Towards Verication of Component Compositions Incorporating Variability. In: The 20th International Con- ference on Transformative Science and Engineering, Business and Social Innovation, 202207. (2015) 32. Mehta, N. R., Medvidovic, N., Phadke, S.: Towards a taxonomy of software connec- tors. In: Proceedings of the 22nd international conference on Software engineering. 178187 (2000) 33. Suloglu, S., Tekinerdogan, B., Dogru, A. H.: XChor: Chreography Language For Integration of Variable Orchestration Languages. In: 3rd International Symposium on Business Modeling and Software Design, 2013, Noordwijkerhout, Netherlands. (2013) 513