<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="tr">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Özellik Modelleri ve Temsil Ettikleri Ürün Tipleri Arasındaki İlişkilerin Çözümlenmesi</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Ahmet</forename><forename type="middle">Serkan</forename><surname>Karataş</surname></persName>
							<email>karatas@ceng.metu.edu.tr</email>
							<affiliation key="aff0">
								<orgName type="department">Orta Doğu Teknik Üniversitesi</orgName>
								<orgName type="institution">Bilgisayar Mühendisliği Bölümü</orgName>
								<address>
									<settlement>Ankara</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Halit</forename><surname>Oğuztüzün</surname></persName>
							<email>oguztuzun@ceng.metu.edu.tr</email>
							<affiliation key="aff0">
								<orgName type="department">Orta Doğu Teknik Üniversitesi</orgName>
								<orgName type="institution">Bilgisayar Mühendisliği Bölümü</orgName>
								<address>
									<settlement>Ankara</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Özellik Modelleri ve Temsil Ettikleri Ürün Tipleri Arasındaki İlişkilerin Çözümlenmesi</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">DA3AB0BF951DC616C07564560732BE48</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-23T19:47+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Yazılım ürün hatları</term>
					<term>özellik modelleri</term>
					<term>öznitelik-tabanlı değişkenlik</term>
					<term>ürün tipleri</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Özellik modellerinde özniteliklerin etkin bir şekilde kullanılması yeni bir değişkenlik türü olan öznitelik-tabanlı değişkenliğin doğmasına yol açmıştır. Literatürde, bu değişkenlik türünün ortaya çıkardığı gereksinimlerin karşılanabilmesi için yazılım ürün hatlarındaki ürün kavramı yeniden yorumlanmış ve yeni ürün tipleri tanımlanmış durumdadır. Bu bildiride, özellik modelleri ve temsil ettikleri yeni ürün tipleri arasındaki ilişkiler incelenmektedir. Bu amaç doğrultusunda tasarlanan bir dizi deney aracılığıyla, örnek bir özellik modeli evrim sürecine tabi tutulduğunda modeldeki değişikliklerin temsil edilen ürün yelpazesini oluşturan farklı tiplerdeki ürünleri nasıl etkilediği tartışılmaktadır. Bunun yanı sıra, ürün tiplerindeki farklılaşmanın yol açacağı dallanmanın, dinamik sistemlerde gereksinim duyulan model ve temsil ettiği ürünler üzerindeki analizlerin hızlı ve verimli bir şekilde gerçekleştirilmesi ihtiyacını nasıl etkileyeceği hakkında fikir sağlaması için çeşitli analiz operasyonlarının performans verileri sunulmaktadır.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="tr">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Giriş</head><p>Yazılım ürün hatları gün geçtikçe daha çok şirket tarafından kullanılmakta ve elde edilen başarı hikâyeleri sayesinde kendisine daha sağlam bir yer edinmektedir. Yazılım ürün hatlarının sağladığı; üretkenliğin ve kalitenin 10 kata kadar arttırılması, maliyetin %60'a varan değerlerde azaltılması, gereken iş gücünün %87'ye varan oranlarda azaltılması, pazara sunum zamanının %98'e varan değerlerde azaltılması <ref type="bibr">[8]</ref> gibi yararlar bu yaklaşımın popülaritesini her geçen gün arttırmaktadır. Yazılım ürün hatları yaklaşımındaki en önemli konulardan biri, ürün ailesini oluşturan ürünler arasındaki ortaklık ve değişkenliklerin verimli bir şekilde modellenmesi ve yönetilmesi hususudur. Bir yazılım ürün hattının başarısı büyük ölçüde bu noktaya bağlıdır <ref type="bibr" target="#b2">[3]</ref>. Yapılan yakın tarihli bir literatür incelemesine göre <ref type="bibr" target="#b3">[4]</ref> bu amaç doğrultusunda kullanılması önerilmiş yöntemler arasında en yaygın olarak kullanılanı özellik modelleridir <ref type="bibr" target="#b6">[9]</ref>. 1990'da önerilmesinden bu yana özellik modelleri üzerinde pek çok geliştirme ve ekleme yapılmıştır. Bu eklemelerin arasında öne çıkanlar özelliklere ve özellik grup-larına nicelik eklenmesi <ref type="bibr" target="#b4">[5]</ref> ve özelliklere öznitelikler eklenmesi <ref type="bibr" target="#b5">[6]</ref> olarak sayılabilir. Modellerdeki özelliklere özniteliklerin eklenmesiyle elde edilen genişletilmiş özellik modelleri özniteliklerin kullanılmasıyla alan bilgisinin doğal bir şekilde modellenmesine izin verirler. Ayrıca, özniteliklerin dallar arası karmaşık kısıtlarda yer almasına izin verilmesiyle birlikte <ref type="bibr" target="#b7">[10]</ref> kimi gereksinimlerin genişletilmiş özellik modellerinde etkili ve doğal bir şekilde ifade edilebilmesinin yolu açılmıştır.</p><p>Ancak özniteliklerin karmaşık kısıtlarda kullanılmasına izin verilmesi bazı yeni gereksinimleri doğurmuştur. Bu gereksinimler, önceden temel değişkenlik birimi olarak sadece özellikler göz önüne alınırken, özniteliklerin de bir değişkenlik kaynağı olarak ele alınması ihtiyacını ortaya çıkarmıştır. İhtiyacın karşılanabilmesi için ise yeni bir değişkenlik türü olan öznitelik-tabanlı değişkenlik kavramı tanımlanmıştır <ref type="bibr" target="#b8">[11]</ref>. Bu yeni değişkenlik türünün getirdiği yenilikler ışığında özellik, konfigürasyon ve ürün gibi temel kavramlar yeniden yorumlanmış ve bu kavramlar yeniden tanımlanarak farklı alt tiplerden oluşan bir dizi çeşitliliğe gidilmiştir <ref type="bibr" target="#b8">[11]</ref>. Bu çeşitlilik farklı niteliklere sahip farklı ürün tiplerini de içermektedir.</p><p>Bu çalışmada yeni ürün tiplerinin temsil edildikleri modellerle ve birbirleriyle olan ilişkilerinin incelenmesi amaçlanmıştır. Bu doğrultuda bir araştırma denizaltısı için örnek bir özellik modeli inşa edilmiştir. Modelin gerçekçi nitelikler taşıması için fikir sağlaması açısından A.B.D. Deniz Kuvvetleri için hazırlanmış bir araştırma raporundan <ref type="bibr" target="#b9">[12]</ref> yararlanılmıştır (ancak bu model anılan dokümanda tarif edilen denizaltının tam bir modeli değildir). Elde edilen model bir evrim sürecine tabi tutulmuş, süreç boyunca modele yeni öznitelikler ve karmaşık kısıtlar eklenerek daha zengin modeller elde edilmiştir. Bu sırada yapılan gözlemler kullanılarak şu iki soruya yanıt aranmıştır: 1) Belli bir modelin temsil ettiği farklı ürün tiplerine ait ürün kümeleri arasındaki ilişkiler nelerdir? 2) Bir modelle, bu modelin temsil ettiği belli bir ürün tipine ait ürün kümesinin arasındaki ilişkiler nelerdir ve model evrim geçirdiğinde bu ilişkiler temsil edilen ürün kümelerini nasıl etkiler? Bu soruların yanıtının verilebilmesi için modeller üzerinde çeşitli analizlerin yapılmasına gereksinim duyulmuştur. Analizler yapılırken performans verileri de kaydedilmiş ve çalışmanın bir yan sonucu olarak elde edilen bu veriler de incelenmiştir.</p><p>Bu bildirinin geri kalanı şu şekilde düzenlenmiştir. 2. Bölümde bu çalışmaya zemin oluşturan kavramlar sunulmuştur. 3. Bölümde evrim sürecinde elde edilen modeller ve bu modellerden elde edilen farklı tiplerdeki ürün kümelerinin arasındaki ilişkiler incelenmiştir. 4. Bölümde deney sürecinde gerçekleştirilen kimi analizlerin performans verileri sunulmuştur. Son bölüm olan 5. Bölümde ise elde edilen sonuçlar yorumlanmıştır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>2</head><p>Art Alan</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Özellik Modelleri</head><p>Bir özellik bir kavrama (sistem, bileşen, vb.) ait olan ve o kavramla ilgili paydaşlar için ayırt edilebilir durumdaki her türlü karakteristiktir <ref type="bibr" target="#b11">[14]</ref>. Özellikler işlevsel yetenekler olabilecekleri gibi, işlevsel olmayan bağlam, kalite, gerçekleştirim gibi hususlara da ait olabilirler. Bir özellik modeli ise hiyerarşik olarak düzenlenmiş olan bir küme özellik, bu özellikler arasındaki dağılma kurallarını tanımlayan ayrışma ilişkileri, rasgele özellikler arasındaki ilişkileri tanımlayan dallar arası kısıtlar ve özellik tercihi için gerekçeler, çeşitli problemlerin/kararların alt yapısını açıklayan notlar gibi ek bilgileri içeren bir yapıdır <ref type="bibr" target="#b6">[9]</ref>. Özellik modellerinde bir anne özellik ile çocukları arasındaki ilişkileri tanımlayan dört çeşit ayrışma ilişkisi bulunur: zorunlu, seçmeli, alternatif, veya. Bunların yanı sıra farklı dallarda bulunan rasgele özellikler arasındaki ilişkileri tanımlayan iki çeşit kısıt bulunmaktadır: gerektirir, dışlar. Şekil 1'de bu ilişkileri içeren farazi bir özellik modelini gösteren bir özellik çizeneği verilmiştir.</p><p>Şekil 1. Örnek bir özellik modeline ait çizenek Genişletilmiş özellik modelleri öznitelikler aracılığıyla özellikler hakkında ekstra bilgi sağlanmasına olanak verir. Bir özelliğe ait bir öznitelik özelliğin ölçülebilir herhangi bir karakteristiğidir <ref type="bibr" target="#b1">[2]</ref>. Genişletilmiş özellik modelleri özniteliklerin model üzerinde tanımlanan kısıtlarda yer alabilmesine izin vermektedir <ref type="bibr" target="#b7">[10]</ref>. Örneğin, genişletilmiş özellik modellerinde "Eğer Ö1 özelliğine ait n1 özniteliğinin değeri 50'den fazla ise ve üründe Ö2 özelliği bulunuyorsa, o zaman Ö3 özelliği de ürüne dahil edilmelidir ve Ö4 özelliğinin n4 özniteliğinin değeri 80-180 aralığında olmalıdır" gibi kısıtlar tanımlanabilmektedir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Öznitelik-tabanlı Değişkenlik ve Ürün Tipleri</head><p>Klasik ürün tanımı içerilen ve dışarıda bırakılan özellikler üzerinden verilir <ref type="bibr" target="#b0">[1]</ref>, öznitelikler hakkında ise bir şey söylenmez. Ancak özniteliklerin etkin bir şekilde kullanılmasıyla doğan öznitelik-tabanlı değişkenlik bu tanımın yetersiz kalmasına neden olmuştur. Örneğin, bir modelde "Ö1 özelliğinin n1 özniteliğinin değeri 6'dan fazlaysa Ö2 özelliği üründe içerilsin, değilse dışarıda bırakılsın" şeklinde bir kısıt varsa, elde edilen ürünlerin modele göre geçerliliğinin denetlenmesi sadece içerilen ve dışarıda bırakılan özelliklere bakılarak yapılamaz, özniteliklerin de değerlerinin denetlenmesi gerekir.</p><p>Öznitelik-tabanlı değişkenliğin getirdiği gereksinimlerin karşılanabilmesi için ürün kavramı yeniden yorumlanmış ve öznitelikler de hesaba katılarak ürün tanımı yeniden yapılmıştır <ref type="bibr" target="#b8">[11]</ref>. Yeni tanımla birlikte ürünler dört tipe ayrılmıştır: F-ürünler, Pürünler, uygun P-ürünler ve C-ürünler. Bu tiplerin hiçbirisi özellik-tabanlı değişkenlik içermez (yani hangi özelliklerin içerildiği, hangilerinin dışarıda bırakıldığı kesin olarak belirlidir). Ancak öznitelik açısından farklar içerirler.</p><p>F-ürünler hiçbir değişkenlik içermezler, yani sahip oldukları tüm özniteliklerin değerleri kesin olarak belirlenmiştir. P-ürünlerde ise en az bir özniteliğin alabileceği değer henüz tam olarak belirlenmemiştir (yani üründe belirtilen ve özniteliğe hangi değerlerin atanabileceğini belirten A-tanım kümesindeki birden fazla değerden istediği birini seçmesine halen izin verilmektedir). Uygun P-ürünler, P-ürünlerin bir alt kümesini oluşturur. Bir ürünün bu kategoriye dâhil olabilmesi için üründeki özniteliklere atanmasına izin verilen değerler kullanıldığında bu üründen en az iki farklı ve geçerli F-ürün türetebilmek mümkün olmalıdır. C-ürünler de P-ürünlerin bir alt kümesini oluştururlar. Bir ürünün bu alt kümeye dâhil olabilmesi için üründeki özniteliklere atanmasına izin verilen değerlerden hangisi seçilirse seçilsin türetilen F-ürün modele göre geçerli bir ürün olmak zorundadır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Ürün Tipleri Arasındaki İlişkiler</head><p>Bir özellik modelinin semantik karşılığı modelin temsil ettiği ürün kümesidir <ref type="bibr" target="#b10">[13]</ref>. Bu nedenle, genişletilmiş özellik modellerinin yeni ürün tiplerinin ortaya çıkmasından semantik seviyede nasıl etkilendiğini anlayabilmek için bir grup deney tasarlanmıştır. Bu bölümde gerçekleştirilen deneyler ve sonuçları sunulacaktır. Deneylerin amacı sadece öznitelik-tabanlı değişkenliğin etkilerini analiz etmektir. Bu nedenle öznitelik içermeyen değişkenler (örnek modeldeki özellikler, özellikler arasındaki hiyerarşik ayrışma ilişkileri ve öznitelik içermeyen kısıtlar) deney sürecinde sabit tutulmuştur. Deneylere örnek bir temel özellik modeli ile başlanmış ve deney adımları sırasında bu örnek model bir evrim sürecine tabi tutulmuştur. Ancak evrim sırasında sadece öznitelikler ve öznitelik içeren kısıtlar bazında değişiklikler yapılmıştır. Bu sayede modelin temsil ettiği ürün kümesi üzerinde özniteliklerin kullanımdan kaynaklanmayan farklar oluşması önlenmiştir.</p><p>Başlangıçta bir araştırma denizaltısı ailesi için örnek bir temel özellik modeli (Model-0) inşa edilmiştir. Model-0 genişletilmiş bir özellik modeli değildir, dolayısıyla herhangi bir öznitelik içermemektedir. Bu modelde herhangi bir dallar arası kısıt bulunmadığı varsayılmıştır. Model-0'ı temsil eden özellik çizeneği Şekil 2'de verilmiştir.  Yukarıda anılan ilk başlık altında sayılabilecek basit bir gözlem temel bir özellik modelinin temsil ettiği ürün sayıları üzerinedir. Sonuçlar Model-0'dan herhangi bir Pürün, uygun P-ürün ya da C-ürün türetilemediğini göstermektedir. Ürün tipleri sunulurken verilen tanımlar herhangi bir özniteliğe sahip olmayan bir özelliğin, özelliği içeren konfigürasyon veya ürün ne olursa olsun, her zaman F-özellik olarak değerlendirileceğini belirtmektedir. Model-0 gibi temel özellik modelleri öznitelik içeren hiçbir özellik içermedikleri için, bu modellerden türetilebilecek tüm konfigürasyon ve ürünler sadece F-özellikler içerecek, dolayısıyla türetilen tüm konfigürasyon ve ürünler F-tipinde olacaktır. Bu nedenle Model-0'ın durumu bir tesadüf değildir ve tüm temel özellik modelleri aynı durumda olacaktır, zira sadece genişletilmiş özellik modelleri P-konfigürasyon ve P-ürün temsil etme yeteneğine sahiptir.</p><p>İlk başlıkta görülmesi beklenen bir başka ilişki de her bir model tarafından temsil edilen P-ürün, uygun P-ürün ve C-ürünlerin sayıları arasındaki ilişkidir. Tablo incelendiğinde tüm modeller için aşağıdaki ilişkinin geçerli olduğu görülmektedir: P-ürün sayısı ≥ uygun P-ürün sayısı ≥ C-ürün sayısı <ref type="bibr" target="#b0">(1)</ref> Bu ilişki sadece bu deneyde kullanılan modeller için değil, tüm temel ve genişletilmiş özellik modelleri için geçerli olacaktır, çünkü ürün tipi tanımları şu iki sonucu doğurmaktadır: (i) her C-ürün aynı zamanda bir uygun P-üründür, (ii) her uygun P-ürün aynı zamanda bir P-üründür.</p><p>Bir sonraki gözlemimiz de ilk başlığa aittir ve bir genişletilmiş özellik modelinin temsil ettiği F-ürün ve P-ürün sayıları üzerinedir. Sonuçlar deneyde kullanılan tüm modeller için temsil edilen P-ürün sayısının F-ürün sayısını aştığını göstermektedir. Bu durumun nedeni, bir sonraki paragrafta detaylı bir şekilde tartışıldığı üzere, tanım kümelerinde üç veya daha fazla değer bulunduran özniteliklere sahip özelliklerin bulunmasıdır.</p><p>Eğer bir özellik belirtilmiş tanım kümesinde n tane değer içeren bir özniteliğe sahipse, bu özelliği içeren potansiyel F-ürün sayısı n kadar artacaktır (yani belirtilmiş tanım kümesi n tane tek elemanlı alt küme içerecektir ve bu alt kümelerin her biri farklı bir F-üründe A-tanım kümesi olarak kullanılabilir). Öte yandan, potansiyel Pürün sayısı en kötü durumda (örneğin, öznitelik içeren başka hiçbir özellik yoksa ve söz konusu özellik başka hiçbir öznitelik içermiyorsa) 2 n -n -1 kadar artacaktır (çünkü n tane eleman içeren bir kümenin 2 n -n -1 tane iki veya daha fazla eleman içeren alt kümesi vardır ve bu alt kümelerin her biri farklı bir P-üründe A-tanım kümesi olarak kullanılabilir). Bu en kötü durumda bile, eğer özniteliğin tanım kümesinde üç veya daha fazla değer varsa potansiyel P-ürün sayısı potansiyel F-ürün sayısından daha fazla olacaktır (çünkü n ≥ 3 ise her zaman 2 n -n -1 &gt; n olacaktır).</p><p>Bir genişletilmiş özellik modelinde, belirlenmiş tanım kümesinde üç veya daha fazla değer içeren öznitelikler varsa o modelden türetilebilecek P-ürün sayısı türetilebilecek F-ürün sayısından genellikle fazla olacaktır. Ancak bu öngörü bazen doğru olmayabilir. Örneğin, böyle öznitelikler nadiren bir ürüne dâhil olan özelliklere aitse etkileri de sınırlı olacaktır; dolayısıyla zaman zaman türetilen F-ürün sayısı P-ürün sayısından fazla olabilir, ancak bu durumun özniteliklerin yoğun olarak kullanıldığı modellerde pek ortaya çıkmayacağı öngörülmektedir.</p><p>Ayrıca genişletilmiş özellik modelindeki öznitelik sayısı arttıkça F-ürün sayısıyla P-ürün sayısı arasındaki oranın büyüdüğü gözlemlenmektedir. Örneğin, bu oran sadece bir öznitelik içeren Model-1 için 1:1,6 (200:320), üç öznitelik içeren Model-2 için 1:21,4 (760:16.280), beş öznitelik içeren Model-3 için ise 1:200,8 (760:152.600) şeklinde görülmektedir. Öznitelik sayısındaki artış A-tanım kümelerinin olası kombinasyonlarının sayısında artışa neden olacağı ve olası tüm kombinasyonlardaki artış olası tek elemanlı alt kümelerin sayısındaki artıştan daha hızlı olacağı için özniteliklerin birleşik etkisi oranlardaki P-ürünler lehindeki değişimlere yol açmaktadır. Bu nedenle, model ne kadar yoğun şekilde öznitelik içeriyorsa bu oranın da o denli yüksek olacağı sonucuna varılabilir.</p><p>Tartışacağımız son gözlem ikinci alt başlığa aittir. Eğer rasgele bir ürün tipi seçecek ve bu ürün tipi için her bir modelin temsil ettiği ürün sayısını inceleyecek olursak sayıların hemen hemen her defasında değiştiği görülmektedir. Örneğin, C-ürünler ele alınacak olursa Model-0'ın 0, Model-1'in 200, Model-2'nin 3.080 ve Model-3'ün 9.608 adet C-ürün temsil ettiği görülmektedir. Evrim sürecinde modellere her bir adımda yeni öznitelik ve dallar arası kısıtlar eklendiği için bu durum şaşırtıcı değildir. Ancak değişimlerdeki oranların farklı ürün tipleri için farklı değerlerle ortaya çıkması ilginç bir davranış olarak gözlenmektedir.</p><p>Örneğin, sadece Model-1 ve Model 2'yi göz önüne alınacak olursa değişim oranlarının F-ürünler için 1:3,8, P-ürünler için 1:50,1, uygun P-ürünler için 1:53,7, Cürünler içinse 1:15,4 olduğu görülmektedir. Yani oranlar ürün tiplerinde farklılık göstermektedir. Model-2 ve Model-3 için bu oranlara bakıldığında değerlerin 1:1, 1:9,4, 1:10,5 ve 1:3,1 şeklinde olduğu görülmektedir. Dolayısıyla, bir özellik modeli evrim geçirdiğinde farklı ürün tiplerinin evrimden farklı oranlarda etkilenebileceği görülmektedir. </p><formula xml:id="formula_0">Model-0 - - - - - Model-1 ∅ - - - - Model-2 ∅ ∅ {800} - - Model-3 ∅ ∅ {800} {1} ∅</formula><p>Deneyin sonraki aşamasında örnek modellerde ölü öznitelik değeri olup olmadığı irdelenmiştir. Tablo 2'de sunulan sonuçlar Model-3'teki İşletim Sistemi.sürüm özniteliğinin tanım kümesindeki 1 değerinin ve Model-2 ve Model-3'teki Anten.frekans özniteliğindeki 800 değerinin ölü öznitelik değerleri olduğuna işaret etmektedir. Bir özellik modelinde ölü öznitelik değerlerinin bulunması kullanıcıya yanlış izlenim vermek gibi istenmeyen durumlara yol açacağından anılan değerler ilgili modellerden çıkarılmış ve Model-2´ ve Model-3´ olarak isimlendirilen yeni modeller elde edilmiştir. Model-2´ Anten.frekans özniteliğinin tanım kümesinin {1600, 1900} olması (yani 800 değerinin orijinal tanım kümesinden çıkarılmış olması) haricinde atası olan Model-2 ile aynıdır. Benzer şekilde, yeni elde edilen Model-3´ Anten.frekans özniteliğinin tanım kümesinin {1600, 1900} olması (yani 800 değerinin orijinal tanım kümesinden çıkarılmış olması) ve İşletim Sistemi.sürüm özniteliğinin tanım kümesinin {2, 3} olması (yani ölü değer olan 1'i içermemesi) haricinde atası olan Model-3 ile aynıdır. Yeni modeller elde edildikten sonra bu modellerin temsil ettiği farklı tipteki ürünlerin sayıları hesaplanmıştır. Elde edilen sonuçlar Tablo-3'te sunulmaktadır. Göze çarpan ilk nokta yeni modeller tarafından temsil edilen F-ürün sayısının modellerin ataları tarafından temsil edilen F-ürün sayısına eşit olmasıdır. Ölü öznitelik değerleri hiçbir F-üründe kullanılmayan değerler olarak tanımlanmış olduğu için bu beklenen bir durumdur. Buna ek olarak, yeni modeller ve ataları tarafından temsil edilen C-ürünlerin sayılarının da eşit olduğu görülmektedir. Bu eşitlik F-ürünlerle Cürünler arasındaki sıkı ilişkiden kaynaklanmaktadır. Bir ürünün C-ürün olarak nitelendirilebilmesi için, üründeki özniteliklere A-tanım kümelerinden hangi değer atanırsa atansın geçerli bir F-ürün elde edilebilmesi gerekmektedir. Dolayısıyla, eğer bir Cüründeki herhangi bir A-tanım kümesi bir değer içeriyorsa, o değer mutlaka en az bir F-üründe de bulunmak zorundadır. Ancak, ölü bir öznitelik değeri herhangi bir Füründe bulunmayan değerdir, dolayısıyla bir C-üründe de bulunamaz. Sonuç olarak, bir modelde ölü öznitelik değerlerinin bulunması ya da bulunmaması model tarafından temsil edilen F-ürün veya C-ürün yelpazesini hiçbir şekilde etkilemeyecektir.</p><p>Ancak, P-ürün ya da uygun P-ürünlere bakıldığında durum farklıdır. Model-2 ve Model-2´ göz önüne alındığında temsil edilen P-ürünlerin sayısının 16.280'den 7.760'a düştüğünü (%52.4'lük bir düşüş), uygun P-ürünlerin sayısının ise 12.880'den 6.440'a düştüğü (%50'lik bir düşüş) görülmektedir. Model-3 ile Model-3´ arasındaki durum benzer olmakla birlikte daha da şiddetlidir; temsil edilen P-ürün sayısı 152.600'den 37.580'e (%74.6'lık bir fark), temsil edilen uygun P-ürün sayısı ise 135.056'dan 33.764'e (%75'lik bir fark) düşmüştür. Bu sonuçlar bir sonraki paragrafta detaylıca incelenmektedir.</p><p>P-ürünler (ve benzer şekilde uygun P-ürünler) üründe içerilen A-tanım kümelerine katı kısıtlamalar koymazlar. Örneğin, bir P-ürün ya da uygun P-üründeki bir A-tanım kümesi, bu üründen türetilebilecek hiçbir F-üründe bulunmayacak değerler içerebilir. Bu esneklik P-ürün ve uygun P-ürünlerin içerdikleri A-tanım kümelerinde ölü değerler bulunmasına izin verir, dolayısıyla kabul edilebilir tanım kümelerinin sayısını arttırır. Örneğin, Anten.frekans özniteliğini ele alalım. Eğer Model-3´ tarafından temsil edilen P-ürünlerden n tanesi Anten özelliğini içeriyorsa, Model-3 tarafından temsil edilen P-ürünlerden 2n tanesi Anten özelliğini içerecektir (yani Model-3´ tarafından temsil edilen her bir ürün için Model-3 tarafından temsil edilen iki ürün olacaktır; ürünün tam bir kopyası ve bu üründeki Anten.frekans özniteliğinin ölü değer olan 800 değerini içeren bir kopyası). Aynı sav uygun P-ürünler için de geçerlidir. Dolayısıyla, ölü öznitelik değerlerinin çıkarılması temsil edilen P-ürün ve uygun P-ürünlerin sayısında ciddi düşüşlere olanak sağlayabilir. Bu durum, temsil edilen ürün sayısı çok fazla olduğunda ve analizler için ayrılabilecek kaynaklar (zaman, işlem gücü, kayıt kapasitesi, vb.) sınırlı olduğunda ürün hattındaki değişkenliğin yönetiminde önemli farklar yaratabilir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Gerçekleştirim ve Performans</head><p>Bir önceki bölümde de sunulduğu gibi deneylerde kullanılan özellik modelleri çok fazla özelliğe sahip olmamasına rağmen çok yüksek sayılarda ürün temsil etmektedir. Dolayısıyla özellik modelleri üzerindeki analizleri elle gerçekleştirmek pratikte müm-kün olmamaktadır. Bu nedenle deneylerde kullanılan modeller üzerindeki analizler de otomatik bir şekilde yapılmıştır. Literatürde belirtilmiş çok sayıda analiz operasyonu (tüm ürünleri bulma, filtreleme, ürün geçerlilik denetimi, modelin değişkenlik faktörünü hesaplama, vs.) bulunmaktadır <ref type="bibr" target="#b0">[1]</ref>. Klasik yazılım ürün hatları üzerindeki analizler genellikle tasarım sırasında yapıldığı için zaman ve kaynak açısından önemli kısıtlamalara tabi değildirler. Ancak dinamik yapılı sistemler söz konusu olduğunda, bu analizler çalışma sırasında yapılacağı için, analizlere ayrılacak işlem gücü, bellek, zaman gibi kaynaklar kısıtlı olabilir. Bu nedenle, bu çalışmada performans değerleri sunulacak operasyonlar seçilirken dinamik sistemlerde çalışma sırasında gerçekleşebilecek evrim ve yeniden konfigürasyon işlemleri için ihtiyaç duyulabilecek operasyonlar göz önüne alınmıştır.</p><p>Analizleri gerçekleştirebilmek için ilk olarak modeller elle bir kısıt mantık programına eşlenmiştir. Bu işlem sırasında hedef platform olarak SICStus Prolog [7] kullanılmıştır. Eşleme ve analiz operasyonlarının gerçekleştirimi için SICStus Prolog tarafından sunulan sonlu tanım kümeleri, yani clp(FD) kütüphanesi kullanılmıştır. Bu amaçla kısıt mantık programlama dillerinin sunduğu listeler ve kümeler gibi yapılardan yoğun bir şekilde yararlanılmıştır. Ayrıca probleme özgü arama stratejilerinin belirlenebilmesi için findall ve labeling gibi geriye dönük aramalar yapabilen yüksek seviye yapılar kullanılmıştır.  </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Sonuçlar</head><p>Bu bildiride teorik altyapısı <ref type="bibr" target="#b8">[11]</ref>'de kurulmuş olan, özellik modellerinde özniteliklerin etkili bir şekilde kullanılmasıyla ortaya çıkmış öznitelik-tabanlı değişkenliğin doğurduğu gereksinimleri karşılamak için tanımlanmış farklı ürün tiplerinin, pratikte temsil edildikleri modelle ve birbirleriyle olan ilişkileri incelenmiştir. Bu amaçla bir araştırma denizaltısı için inşa edilmiş örnek bir özellik modeli bir evrim sürecine tabi tutulmuş, evrimleşen modellerin temsil ettikleri farklı tiplerdeki ürün ailelerindeki değişimler gözlemlenmiştir. Yapılan deneyler, içerisinde halen öznitelik-tabanlı değişkenlik içeren P-ürün, uygun P-ürün ve C-ürünlerin sayısındaki artışın çok yüksek hızlara ulaşabileceğini göstermektedir. Örneğin, Model-1'den Model-3'e geçişte modellerdeki toplam öznitelik sayısı sadece 5 kat artmışken, P-ürün sayısı 477 kat, uygun P-ürün sayısı 563 kat, Cürün sayısı ise 48 kat artmıştır. Bu nedenle, belirtilen tipteki ürünlerin yönetiminde kullanılacak yaklaşımlarda bu durum mutlaka göz önüne alınmalıdır. İçinde özniteliktabanlı değişkenlik taşımayan F-ürünlerin sayısı ise sadece 9,5 kat artmıştır. Bu sonuçlar, ürünlerdeki öznitelik-tabanlı değişkenliğin ürün çeşitliliğine olanak sağlayarak bir esneklik sağladığını, ancak bunun karşılığında daha fazla kaynak kullanımı gerektirdiğini göstermektedir.</p><p>Literatürde bu çalışmanın konusu olan ürün tipleri için sentaktik ve semantik tanımlar verilmiş durumdadır, ancak bu yeni ürün tiplerine ait ürünlerin bir modelden verimli bir şekilde türetilmesini sağlayacak yöntemler veya algoritmalar sunulmamıştır. Bu çalışmada, içinde öznitelik-tabanlı değişkenlik içeren ürünleri türetme işlemi için kullanılan algoritmalar kaba kuvvet stratejileri kullanmakta, bu da sonuçlara olumsuz olarak yansımaktadır. İlgili ürünleri türetmek için daha verimli algoritmalar geliştirilmesi ihtiyacı gelecekteki araştırmalar tarafından çözülmesi gereken bir problem olarak varlığını sürdürmektedir.</p><p>Bu çalışmadaki deneyler için nispeten küçük ölçekte örnek bir özellik modeli kullanılmıştır. Ancak endüstriyel ölçülerdeki özellik modellerinin daha büyük olabildiği, yüzlerce özellik, öznitelik ve karmaşık kısıt içerebildiği bilinmektedir. Ayrıca, farklı özellik modelleri farklı biçimlere ve farklı karakteristik niteliklere sahip olabilirler. Bu çalışmada sunulan sonuçlar özellik modelleri ve temsil ettikleri ürün tipleri arasındaki ilişkilerin çözümlenmesine dair ilk izlenimleri aktarmaktadır. Farklı deneysel örnekler ve gerçek sistemler üzerinde yapılan benzer çözümlemelerin sayısının artma-sıyla elde edilen verinin hacmi de artacak, bunun sonucunda da daha detaylı ve kesin sonuçlar elde edilebilecektir. Ana hatları bu bildiride çizilmiş olan çözümlemelerin farklı modellere uygulanması gelecekte yapılacak araştırmaların konusu olabilecek bir problemdir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Teşekkür</head><p>Bu çalışma TÜBİTAK ARDEB 1001 -Bilimsel ve Teknolojik Araştırma Projelerini Destekleme Programı çerçevesinde, 215E188 kodlu proje kapsamında desteklenmiştir.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Şekil 2 .</head><label>2</label><figDesc>Araştırma denizaltısı ailesi için temel özellik modeli, Model-0 İkinci adımdan başlayarak bir evrim süreci başlatılmış, ilgili modele her bir adımda yeni öznitelik(ler) ve öznitelik içeren karmaşık kısıt(lar) eklenerek model bir genişletilmiş özellik modeline dönüştürülmüştür. İkinci adımda bu modeldeki Gövde isimli özelliğe tip isminde, tanım kümesi {1, 2, 3} olan bir öznitelik eklenmiştir. Elde edilen genişletilmiş özellik modeli Model-1 olarak adlandırılmıştır. Ayrıca Model-1'e aşağıdaki öznitelik içeren dallar arası karmaşık kısıt eklenmiştir:  Eğer Gövde.tip = 3 ise Gövde özelliği Tekerlek özelliğine gereksinim duyar.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Tablo 4 .</head><label>4</label><figDesc>Seçilmiş analiz operasyonlarına ait performans verileri Milisaniye cinsinden operasyon süresi Model-0 Model-1 Model-2 Model-2´ Model-3 Model-3´</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head></head><label></label><figDesc>Sonraki adımda Model-1'e güç ve frekans isimli iki yeni öznitelik eklenerek Model-2 elde edilmiştir. güç isimli öznitelik Motor özelliğine aittir ve tanım kümesi {200, 300, 400} olarak belirlenmiştir. frekans özniteliği ise Anten özelliğine aittir ve tanım kümesi {800, 1600, 1900} değerlerini içermektedir. Bu özniteliklerin yanı sıra Model-2'ye üç adet öznitelik içeren dallar arası karmaşık kısıt eklenmiştir:Eğer Gövde.tip = 3 ise Gövde özelliği Motor.güç ≥ 300 olmasını şart koşar.  Çelik özelliği Motor.güç ≥ 400 olmasını şart koşar.  Navigasyon özelliği Anten.frekans ≥ 1600 olmasını şart koşar. Son adımda Model-3'ü elde etmek için Model-2'ye iki öznitelik daha eklenmiştir. Bu özniteliklerden birincisi olan sürüm özniteliği İşletim Sistemi özelliğine, ikincisi olan tip özniteliği ise Analiz özelliğine eklenmiştir. sürüm özniteliğinin tanım kümesi {1, 2, 3}, tip özniteliğinin tanım kümesi ise {0, 1, 2} olarak belirlenmiştir. Son olarak Model-3'e aşağıdaki kısıtlar eklenerek modelin son hali oluşturulmuştur:  Navigasyon özelliği İşletim Sistemi.sürüm &gt; 1 olmasını şart koşar.  Eğer İşletim Sistemi.sürüm &lt; 3 ve Analiz özelliği ürüne dahil edilmiş ise İşletim Sistemi özelliği Analiz.tip ≤ 2 olmasını şart koşar.  Organik örnekleme Analiz yazılımının tip'inin 3 veya daha yüksek bir değerde olmasını gerektirir.  Sıvı örnekleme Analiz yazılımının tip'inin 2 veya daha yüksek bir değerde olmasını gerektirir.Özellikler ve ayrışma ilişkileri ilk modelden itibaren değişmeden korunduğu için tüm modeller aynı hiyerarşik yapıya sahiptir. Modeller arasındaki tek fark içerilen öznitelikler ve öznitelik içeren dallar arası karmaşık kısıtlardır. Dört özellik modeli oluşturulduktan sonra etkilerin incelenebilmesi için her bir modelin semantik karşılığı olan ürün kümeleri hesaplanmıştır. Modellerden türetilebilecek tüm ürünlerin sayısı her bir ürün tipi için Tablo 1'de verilmiştir.</figDesc><table><row><cell cols="4">Tablo 1. Her bir modelin temsil ettiği ürün sayıları</cell></row><row><cell>Model-0 Model-1 Model-2 Model-3</cell><cell>F-ürün 80 200 760 760</cell><cell>Ürün Sayısı P-ürün Uygun P-ürün 0 320 240 0 16.280 12.880 152.600 135.056</cell><cell>C-ürün 200 0 3.080 9.608</cell></row></table><note>Tablo 1'de sunulan sonuçların analizi iki başlık altında toplanabilecek bir dizi karakteristik niteliğin gözlemlenebilmesine olanak tanımaktadır. Bir modelin temsil ettiği farklı ürün tipleri arasındaki ilişkiler ilk başlıkta, belli bir tipteki ürünler için evrim sürecine tabi tutulmuş farklı modeller tarafından temsil edilme durumları arasındaki ilişkiler ise ikinci başlıkta toplanabilir. İlerleyen paragraflarda her bir başlık altındaki ilişkilerden seçilmiş örnekler incelenecektir.</note></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_3"><head></head><label></label><figDesc>Ancak kullanılan SICStus Prolog sürümü bir deneme sürümü olduğu için bazı kısıtlamalara sahiptir (örneğin sadece 256 MB bellek ve işlemcinin tek bir çekirdeğini kullanmaktadır). Seçilmiş analiz operasyonları olan tüm ürünler, filtreleme ve geçerli ürün operasyonlarına ait performans verileri Tablo 4'te verilmiştir.</figDesc><table><row><cell cols="6">arasından geçerli olanlar ayıklanmıştır). Bu nedenle otomatik analiz için bu çalışmada kullanılan gerçekleştirimlerden daha verimli ve hızlı bir şekilde çalışacak gerçekleşti-rimler yapmak mümkün olabilir. Analiz operasyonları Intel Core i7 6700HQ işlemciye sahip ve Windows 10 çalıştı-ran bir bilgisayarda koşturulmuştur.</cell></row><row><cell>Geçerli Ürün (C) Filtre (F) Filtre (P) Filtre (uP) Filtre (C) Tüm Ürünler (F) Tüm Ürünler (P) Tüm Ürünler (uP) Tüm Ürünler (C)</cell><cell>1 12 12 13 11 11 13 11 9</cell><cell>1 11 24 24 24 11 54 61 63</cell><cell>1 12 1.024 1.056 1.093 14 4.265 8.287 8.465</cell><cell>1 12 415 401 416 14 2.091 102.631 1 12 7.460 8.758 9.213 14 2.374 109.368 2.442 123.620</cell><cell>1 13 1.378 1.384 1.418 14 20.679 22.125 22.345</cell></row><row><cell cols="6">Analiz operasyonları temelde bir kısıt sağlama problemi olduğu için, kısıt mantık programlama dillerinde birçok farklı şekilde modellenebilir, diğer bir ifadeyle, ope-rasyonlar farklı algoritmalar kullanılarak gerçekleştirilebilir. Bu çalışma sırasında modeller tarafından temsil edilen P-ürün, uygun P-ürün ve C-ürünler bulunurken kaba kuvvet yaklaşımı kullanılmıştır (olası tüm ürünler türetilmiş, daha sonra bu ürünler</cell></row></table></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Automated analysis of feature models 20 years later: a literature review</title>
		<author>
			<persName><forename type="first">D</forename><surname>Benavides</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Segura</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Ruiz-Cortés</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Information Systems</title>
		<imprint>
			<biblScope unit="volume">35</biblScope>
			<biblScope unit="issue">6</biblScope>
			<biblScope unit="page" from="615" to="636" />
			<date type="published" when="2010">2010</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Automated Reasoning on Feature Models</title>
		<author>
			<persName><forename type="first">D</forename><surname>Benavides</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Trinidad</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Ruiz-Cortés</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of CAiSE&apos;05</title>
		<title level="s">LNCS</title>
		<meeting>CAiSE&apos;05</meeting>
		<imprint>
			<date type="published" when="2005">2005</date>
			<biblScope unit="volume">3520</biblScope>
			<biblScope unit="page" from="491" to="503" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">Variability issues in software product lines</title>
		<author>
			<persName><forename type="first">J</forename><surname>Bosch</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Florijn</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Greefhorst</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Kuusela</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Obbink</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Pohl</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the 4 th international workshop on product family engineering (PFE&apos;01)</title>
				<meeting>the 4 th international workshop on product family engineering (PFE&apos;01)</meeting>
		<imprint>
			<date type="published" when="2001">2001</date>
			<biblScope unit="page" from="11" to="19" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">A systematic review of evaluation of variability management approaches in software product lines</title>
		<author>
			<persName><forename type="first">L</forename><surname>Chen</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">A</forename><surname>Babar</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Information and Software Technology</title>
		<imprint>
			<biblScope unit="volume">53</biblScope>
			<biblScope unit="page" from="344" to="362" />
			<date type="published" when="2011">2011</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Formalizing cardinality-based feature models and their specialization</title>
		<author>
			<persName><forename type="first">K</forename><surname>Czarnecki</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Helsen</surname></persName>
		</author>
		<author>
			<persName><forename type="first">U</forename><surname>Eisenecker</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Software Process: Improvement and Practice</title>
		<imprint>
			<biblScope unit="volume">10</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="7" to="29" />
			<date type="published" when="2005">2005</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Generative programming for embedded software: An industrial experience report</title>
		<author>
			<persName><forename type="first">K</forename><surname>Czarnecki</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Bednasch</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Unger</surname></persName>
		</author>
		<author>
			<persName><forename type="first">U</forename><surname>Eisenecker</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the ACM SIGPLAN/ SIGSOFT Conference on Generative Programming and Component Engineering (GPCE 2002)</title>
				<meeting>the ACM SIGPLAN/ SIGSOFT Conference on Generative Programming and Component Engineering (GPCE 2002)</meeting>
		<imprint>
			<date type="published" when="2002">2002</date>
			<biblScope unit="volume">2487</biblScope>
			<biblScope unit="page" from="156" to="172" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<title level="m" type="main">Feature-Oriented Domain Analyses (FODA) Feasibility Study</title>
		<author>
			<persName><forename type="first">K</forename><surname>Kang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Cohen</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Hess</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><surname>Novak</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Peterson</surname></persName>
		</author>
		<idno>CMU/SEI-90-TR-21</idno>
		<imprint>
			<date type="published" when="1990">1990</date>
			<pubPlace>Pittsburgh</pubPlace>
		</imprint>
		<respStmt>
			<orgName>Software Eng. Inst., Carnegie Mellon Univ.</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Technical Report</note>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">From extended feature models to constraint logic programming</title>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">S</forename><surname>Karataş</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Oğuztüzün</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Doğru</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Science of Computer Programming</title>
		<imprint>
			<biblScope unit="volume">78</biblScope>
			<biblScope unit="issue">12</biblScope>
			<biblScope unit="page" from="2295" to="2312" />
			<date type="published" when="2013">2013</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">Attribute-based variability in feature models</title>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">S</forename><surname>Karataş</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Oğuztüzün</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Requirements Engineering</title>
		<imprint>
			<biblScope unit="volume">21</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page" from="185" to="208" />
			<date type="published" when="2016">2016</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<monogr>
		<title level="m" type="main">A Concept of Operations for a New Deep-Diving Submarine</title>
		<author>
			<persName><forename type="first">F</forename><forename type="middle">W</forename><surname>Lacroix</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2002">2002</date>
			<publisher>National Defense Research Institute</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<analytic>
		<title level="a" type="main">Generic semantics of feature diagrams</title>
		<author>
			<persName><forename type="first">P</forename><surname>Schobbens</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">C</forename><surname>Trigaux</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Heymans</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Bontemps</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer Networks</title>
		<imprint>
			<biblScope unit="volume">51</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page" from="456" to="479" />
			<date type="published" when="2007">2007</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<analytic>
		<title level="a" type="main">Software Technology for Adaptable Reliable Systems (STARS)</title>
		<author>
			<persName><forename type="first">M</forename><surname>Simos</surname></persName>
		</author>
		<idno>STARS-VCA025/ 001/00</idno>
	</analytic>
	<monogr>
		<title level="m">Organization Domain Modeling (ODM) Guidebook Version 2.0</title>
				<meeting><address><addrLine>Manassas, VA</addrLine></address></meeting>
		<imprint>
			<publisher>Lockheed Martin Tactical Defense Systems</publisher>
			<date type="published" when="1996">1996</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
