Çoklu Ürün Hatları için Hazırlanan Mimari Bakış Açıları ile Radar ve Elektronik Harp Alanının Mimari Tasarımı

Çoklu Ürün Hatları için Hazırlanan Mimari Bakış Açıları ile Radar ve Elektronik Harp Alanının Mimari Tasarımı Bedir Tekinerdoğan 1, Özgü Özköse Erdoğan 2, Onur Aktuğ 3 1 Bilgisayar Mühendisliği Bölümü, Bilkent Üniversitesi, Ankara 2,3 Radar Elektronik Harp ve Đstihbarat Sistemleri (REHĐS) Grubu, ASELSAN A.Ş. Ankara 1 e-posta: bedir@cs.bilkent.edu.tr 2 e-posta: ozkose@aselsan.com.tr 3 e-posta: oaktug@aselsan.com.tr Özetçe Yazılım sistemlerinin giderek artan boyut ve karmaşıklığı, ürünlerin, alt ürünlerin bileşimiyle, farklı ürün hatlarında ortaya çıktığı çoklu ürün hatları (ÇÜH) görüşünün ön plana çıkmasını sağlamıştır. Literatür taramaları, çoklu ürün hatları için mimari tasarım ve değerlendirmelerinin yapılabileceği uygun bir modelleme fikrinin ortaya çıkmadığını göstermektedir. Bu makalede, çoklu ürün hatlarını modelleme ve belgeleme amacıyla üç mimari bakış açısı önerilmekte ve Aselsan, REHĐS Grubu, Görev Yazılımları Müdürlüğü (GYM) kapsamında yürütülen çalışmalardaki tecrübeler aktarılmakta, olası mimari tasarım alternatifleri gösterilmekte ve verilen bakış açılarına uygun mimari tasarımın seçilmesi değerlendirilmektedir. Anahtar kelimeler ürün hattı kapsamı, ürün hattı organizasyonu 1. Giriş Yazılım ürün hattı yaklaşımının benimsenmesiyle elde edilecek yararlar pek çok yazar tarafından analiz edilmiş ve tartışılmıştır [3][11][14]. Ürünlerin daha etkin geliştirilmesi, rekabet gücünü artıran ürünün pazara çıkarılması hızının artırılması ve yazılım kalitesinin yükseltilmesi, yazılım ürün hatları mühendisliği sürecinin benimsenmesi motivasyonunu sağlayan önemli etkenlerdir [14]. Bu hedeflerle uyumlu olarak farklı yazılım ürün hattı mühendisliği süreçleri önerilmiş ve pek çok firma ürün kalitesi ile pazara çıkma hızını artırmak ve üretim maliyetini azaltmak amacıyla bir yazılım ürün hattı mühendisliği yöntemini benimsemeyi hedeflemiştir. Son zamanlardaki eğilimler, artan yazılım büyüklüğü ve karmaşıklığı nedeniyle, endüstride yazılım ürün hattının yeniden kullanım ölçeğinin artacağını göstermektedir. Bu kapsamda pek çok araştırmacı ürünlerin farklı ürün hatlarındaki alt ürünlerden meydana geldiği çoklu ürün hatlarına (ÇÜH) ihtiyaç duyulduğunu belirtmiştir [10][12]. Çoklu ürün hatlarını tanımlarken öne çıkan önemli konulardan biri ÇÜH yi oluşturacak alt ürün hatlarının belirlenmesidir. Varolan yaklaşımlar, sistemin uygun ölçüde alt ürün hatlarına ayrıştırılmasında ve bu ürün hatları arasındaki ilişkilerin belirlenmesinde yetersiz kalmaktadır. ÇÜH nin farklı ürün hatlarına ayrıştırılmasında uygun bir modelleme gösterimi ve kılavuzunun sağlanması önemlidir. Bu makalenin iki yönlü bir katkı getireceği değerlendirilmektedir. Đlk olarak ÇÜH için mimari bakış açıları önerilmektedir. Makale içinde Ürün Hattı Ayrıştırma Bakış Açısı, Ürün Hattı Bağımlılık Bakış Açısı ve Ürün Hattı Konfigürasyon Bakış Açısı tanımlanmaktadır. Bu bakış açılarının hazırlanmasında varolan bakış açılarından esinlenilmiş ancak ÇÜH nin yapılandırılması mantığının belirtimi için gereken üst seviye görünümlerin oluşturulmasına odaklanılmıştır. Makalenin ikinci katkısının çoklu ürün hattı modelleme ve analiz çalışmalarının endüstriyel bir örnek üzerinde yapılmasıyla oluşan tecrübelerin aktarılması olacağı değerlendirilmiştir. Makalede, radar elektronik harp sistemleri üzerinde çalışan Aselsan A.Ş. REHĐS grubu bünyesindeki ÇÜH ayrıştırma çalışmalarına ilişkin örnekler verilmektedir [1]. Aselsan, yüksek teknolojide, modern savunma sanayi sistemleri geliştiren öncü bir kuruluştur. Tanımlanan bakış açıları ile ÇÜH için dört farklı mimari ayrıştırma alternatifi analizi yapılmıştır. Çalışma ve tecrübelerimiz ÇÜH mimarisini tanımlarken belirlenen bakış açılarının önemli bir gereksinim olduğunu göstermektedir. Belirtilen mimari bakış açıları ile ÇÜH tasarım kararları ile ilişki kurulabilecek ve tasarım alternatifleri arasında seçim yapılabilecek bir şekilde tanımlanmıştır. Makalenin bundan sonraki bölümleri şu şekilde organize edilmiştir: 2. bölümde radar elektronik harp sistemleri alanı içinden seçilen örnek durum tanıtılmaktadır. 3. bölümde çoklu ürün hatları betimlenmekte, 4. bölümde tanımlanan ÇÜH nin modellenmesi için mimari bakış açıları verilmektedir. 5. bölümde, 3. bölümde tanımlanan ÇÜH için, verilen mimari bakış açıları kullanılarak, alternatif tasarımların analizi tartışılmaktadır. 6. bölüm ilişkili çalışmaları tanıtırken, 7. bölüm çalışmanın değerlendirilmesine ayrılmıştır. 2. Durum Tanımı Aselsan ın Radar ve Elektronik Harp (REH) sistemleri temel olarak üç ana katmandan oluşmaktadır: Görev Alanı Uygulamaları, Uygulama Destek Servisleri ve Kesişim Alanı Servisleri. Bu katmanlar Radar, Radar Elektronik Harp, Haberleşme Elektronik Harp ve Kendini Koruma sistemleri için temel yapıtaşlarını içerir. Tipik bir ürün verilen bu üç katmandaki yapıtaşlarının konfigürasyonu ile oluşturulur. Katmanların kendileri birer alt sistem değil alt sistemleri oluşturan yapıtaşlarının mantıksal birer paketlemesidir. Alt sistemler varlık temelini oluşturan bileşenlerden oluşur. Aselsan tarafından üretilen pek çok üründe ortak yetenekler yer almaktadır. Bu nedenle Aselsan ürün geliştirmede ürün hatlarına dayalı sistematik bir yeniden kullanım stratejisine yönelmiştir. Bu konudaki en önemli ticari faktörler pazara daha hızlı ürün çıkarma, ürün kalitesini artırma ve toplam maliyeti azaltmaktır. Tüm alanı tek bir ürün hattı olarak ifade etmek mümkündür. Ancak önceki projelerde elde edilen tecrübelerle bu yaklaşımın yeterli olmadığı, geniş bir yelpazede ürün çeşitliliği olan Aselsan sistemleri için 1 115

makul olamayacağı değerlendirilmiştir. Ürünler referans mimariye uygun olarak geliştirilse de alt sistemler farklı ve ilişkisiz alanlarda yer almaktadır. Farklı alanlara ait bu ürünler farklı ekipler tarafından geliştirilmekte, farklı alan bilgisi ve gereksinimler içermekte ve dolayısıyla farklı ürün ailelerini teşkil etmektedir. Ayrıca farklı alt sistemler farklı ürünler olarak değerlendirilmektedir. Örneğin, Uygulama Destek Servisleri katmanındaki Mesajlaşma alt sistemi Kesişim Alanı Servisleri katmanındaki Şifreleme Protokolleri alt sisteminden farklılık gösterir. Her alt sistem temel olarak ayrı bir ürün ailesi olarak ele alınabilir. Ürün ailelerinin birbirinden ayrılması ilgilerin ayrımını ve farklı ürün ailelerinin farklı kapsamlarda kullanımını desteklemektedir. Başka bir faydası da basit, küçük ve kapsamı belirli ürün ailelerinin geniş ve karmaşık ürün ailelerine göre daha kolay yönetilme imkânına sahip olmasıdır. Tüm sistemin gerçekte farklı ve birbiriyle ilişkili ürün ailelerinden meydana geliyor olduğu gözlemi, sistemin doğru ürün hatlarına ayrıştırılması problemini ortaya çıkarmıştır. Tüm sistemler için bir tek yazılım ürün hattı olası değilse sistem hangi ürün ailelerinden oluşmalıdır? Sistem kapsamı doğru belirlenmiş hangi ürün ailelerine ayrıştırılmalıdır? Ayrıştırma hangi kritere göre yapılmalıdır? Fikir iletişimi nasıl bir gösterim ile sağlanabilir? Bu konuların tartışılması amacıyla yetenek modelleme gibi varolan teknikler kullanılmış ancak bu yöntemlerin farklı ürün ailelerinin tanımlanmasında çok fayda getirmediği değerlendirilmiştir. 3. Çoklu Ürün Hatları Çoklu ürün hattı yaklaşımı daha önce farklı araştırmacılar tarafından adreslenmiştir. Bu kapsamda çoklu ürün hatları, iç içe ürün hatları ve ürün hatlarından oluşan ürün hatları aynı kavramı ifade etmek için kullanılmıştır. [12] de yazarlar çoklu ürün hatlarını birbirleriyle ilişkili ve bağımlı yazılım ürün hatları kümesi olarak tanımlamıştır. ÇÜH mühendisliğinde yazılım mimarisinin önemi, bu ürün hattından üretilecek ürünlerin genel mimarisini tanımlaması nedeniyle büyüktür. Paydaşların ilgilerine göre mimariyi tanımlama pratiği farklı mimari gösterimlerle yapılır [2]. Mimari gösterimler, belirli bir konudaki sistem elemanları ile bu elemanlar arasındaki ilişkileri gösterir. Genel olarak, farklı paydaşlar için, ilgilerin ayrıştırılması, modellemenin desteklenmesi ve anlaşılırlık ile iletişimin artırılması amacıyla birden fazla mimari gösterim gerekir. Mimari gösterimler, gösterimin oluşturulması ve kullanılmasını tanımlayan bakış açılarına uyumlu olarak hazırlanır. Literatürde, ilk olarak, mimarinin belgelendirilmesi amacıyla, belirli bir bakış açısı kümesinin önerildiği görülmektedir [2]. Farklı sistemler için farklı ilgi alanlarına ihtiyaç duyulması nedeniyle şimdiki eğilim bakış açısı kümesinin sabitlenmesi yerine ihtiyaca uygun olarak yeni bakış açılarının eklenmesidir. Çoklu ürün hattı konfigürasyonunu tanımlamak her zaman kolay olmayabilir. Pek çok konfigürasyon seçeneğini modelleme, belgeleme ve muhakeme etmek için uygun gösterim yöntemleri gerekir. Mimari modelleme için varolan bakış açıları, hem ürün hattı mimarileri hem de uygulama mimarileri için kullanılabilir. Ancak, çoklu ürün hatları değerlendirildiğinde, bu bakış açılarının, alt seviyedeki farklı ürün hatlarının belirtiminde yeterli olmadığı görülmektedir. Bu anlaşılırlığı ve paydaşlar arası iletişimi güçleştirmekte, ürün hattı ayrıştırım analizinin yapılmasını ve ürün geliştirme yöntemini karmaşıklaştırmaktadır. Bir başka problem ürün hatları kümesi sınırlarının çizilmesinin güçleşmesidir. Tek bir ürün hattı için kapsam belirleme fikirleri tartışılsa da büyük ve karmaşık çoklu ürün hatlarının belirlenmesi için bir kılavuz tanımlanmamıştır. Genel olarak, mimari modelleme amacıyla hazırlanmış bakış açıları hem ürün hatları hem de uygulama mimarileri için kullanılabilir. Çoklu ürün hatlarını tanımlarken ürün hatları mimarilerinin üzerinde bir mimari gösterime ihtiyaç duyulmuştur. Çalışmalarımızda, bu ihtiyaca yönelik olarak, birden fazla ürün hattından oluşan sistemlerde, üst seviye mimariyi tanımlamak ve ürün hatları arasındaki ilişkiyi belirlemek amacıyla çoklu ürün hattı mimarı rolü tanımlanmıştır. 4. bölümde ilk olarak, çoklu ürün hatlarını tanımlamak üzere mimari bakış açılarını tanımlayacağız. Daha sonraki bölümde Aselsan REH uygulamalarında çoklu ürün hatları alternatiflerinden uygun olanın belirlenmesi amacıyla düzenlenen kriterleri ve bu kriterlere uygun seçim işleminin yapılmasını açıklayacağız. 4. Mimari Bakış açıları Çoklu ürün hatlarına ilişkin, literatürde belirtilen bakış açılarını tamamlayıcı olarak üç mimari bakış açısı tanımlanmıştır: Ürün Hattı Ayrıştırma Bakış Açısı (Tablo 1), Ürün Hattı Bağımlılık Bakış Açısı (Tablo 2), Ürün Hattı Konfigürasyon Bakış Açısı (Tablo 3). 4.1 Ürün Hattı Ayrıştırma Bakış Açısı Tablo 1 Ürün Hattı Ayrıştırma Bakış Açısı nı gösterir. Bakış açıları üç tür geliştirme birimini ayrıştırır: Bileşik Ürün Hattı (BÜH), Ürün Hattı (ÜH), ve Ürün Hattı Dışındaki Birim (ÜHDB). Bir BÜH, ÜH lerin ve diğer BÜH lerin bir araya gelmesiyle oluşur. Bir ÜH diğer ÜH leri içeremez. Hem BÜH hem de ÜH ler alt sistemler olarak tanımlanmıştır [2]. Bir alt sistem, (1) tüm sistemin, birbiriyle ilişkili işlevselliğini içeren bir bölümü oluşturan, (2) ayrı olarak çalıştırılabilen, (3) ayrı ve artımsal olarak geliştirilip yüklenebilen bir parçası olarak tanımlanmıştır. Bu açıdan bir ÜHDB sistemin, bir BÜH ya da ÜH gibi bir alt sistemi olmayan bir parçasıdır. ÜHDB örneği olarak sistemin bir parçası olan, kendi içinde ilişkili işlevleri yerine getiren ancak tek başına çalıştırılamayan bir kütüphane verilebilir. ÜHDB lerin UML de varolan paket gösterimi ile uyumlu olduğu değerlendirildiği için ÜHDB bileşimi amacıyla ayrı bir gösterim tanımlanmamıştır. UML paketleri, kendileri de alt paketler içerebilen gruplama mekanizmaları olarak tanımlanmaktadır. Ürün Hattı Ayrıştırma Bakış Açısı nda, üç öğe için yalnızca parçabütün ilişkisi yer almaktadır, Kısıtlar, geçerli bir konfigürasyon hazırlanabilmesi için gerekli kuralları tanımlar. Bu bakış açısı, sistemin özellikle üst seviyede farklı ürün hatlarına ayrıştırılacağı görünümlerin hazırlanması için önemlidir. Bu bilgi tüm sistemin öğrenilmesi ve tasarlanması süreçlerinde gereklidir. Ayrıca ürün hattı ayrıştırımı için gereken girdiler organizasyon yapılanma sürecinde de kullanılabilir. Örneğin her ürün hattı ayrı bir ekiple eşleştirilebilir. 2 116

Tablo 1. Ürün Hattı Ayrıştırma Bakış Açısı Bakış Açısı Öğesi Đsim Özet Öğeler Đlişkiler Kısıtlar Gösterim Tanım Ürün Hattı Ayrıştırma Bakış Açısı Bu bakış açısı bir sistemi farklı ürün ailesi öğelerine ayrıştırma amacıyla kullanılır. Bileşik Ürün Hattı (BÜH) diğer bileşik ürün hattı ve ürün hattı birimlerini barındıran bileşik yazılım ürün ailesi birimi Ürün Hattı (ÜH) tek bir yazılım ürün ailesi birimi Ürün Ailesi Dışındaki Birim (ÜHDB) yazılım ürün ailesi yaklaşımıyla geliştirilmeyen yazılım birimi Birimler ve alt-birimler arası parça-bütün ilişkisi Bir ürün ailesi birimi yalnızca bir üst seviye ürün ailesi biriminin parçası olabilir BÜH birimlerinin ÜH ve ÜHDB parçaları olabilir ÜH birimlerinin yalnızca ÜHDB parçaları olabilir ÜHDB birimlerinin yalnızca ÜHDB parçaları olabilir Şekil 1. Çoklu Ürün Hattını Tanımlayan Örnek Ürün Hattı Ayrıştırma Görünümü 4.2 Ürün Hattı Bağımlılık Bakış Açısı Ayrıştırma ilişkilerinin gösterimi kadar ürün hatları arasındaki etkileşimleri göstermek de önem taşır. Bu amaçla Tablo 2 de görülen Ürün Hattı Bağımlılık Bakış Açısı tanımlanmıştır. Bu bakış açısı Ürün Hattı Ayrıştırma Bakış Açısı ndaki öğeleri içermekle birlikte kullanır ilişkisini de tanımlar. Bir ürün hattı biriminin doğruluğu diğer bir ürün hattının doğru olmasına bağlı ise bu ürün hattı diğerini kullanır. Bu ilişki Görünümler ve Ötesi [2] yaklaşımında tanımlanan Kullanım Stili ile uyumludur. Farklılığı ilişkinin uygulama birimleri yerine tüm ürün hattına uygulanabilmesidir. Ayrıca bir ürün hattı diğer bir ürün hattını kullanıyorsa genel olarak aralarında bir konfigürasyon bağımlılığı da yer alır. Bu durumda bir ürün hattındaki yeteneklerin seçimi diğer ürün hattındaki yeteneklerin de seçilmesini gerektirir [13]. Şekil 1 de ele alınan çalışma konusu için örnek bir ürün hattı ayrıştırma görünümü sunulmaktadır. Bu sistem, üç farklı bileşik ürün hattı (BÜH) (Radar Elektronik Harp - RadEH, Haberleşme Elektronik Harp - HabEH, Radar), dört ürün hattı (ÜH) (HASP, VERY, Seyrüsefer, Kendini Koruma Suit) ve 12 ürün hattı dışındaki birim (ÜHDB) (kütüphaneler) içeren bir bileşik ürün hattı (Radar Elektronik Harp Fonksiyonel Referans Mimarisi - REFoRM) olarak tanımlanmıştır. REFoRM altındaki her bir BÜH iki ÜH den oluşmaktadır. Bu durumda çoklu ürün hattı mimarisi dört farklı ürün hattı (HASP, VERY, Seyrüsefer ve Kendini Koruma Suit) ve BÜH ler içinde tanımlanan altı farklı ÜH den (Radar ED, Radar ET, HabAlan1, HabAlan2, RadarAlan1, RadarAlan2) oluşur. Her ÜH nin kendi alan mühendisliği ve uygulama mühendisliği süreci vardır. Değişkenlik yönetimi ve modelleme her ÜH ye ayrı ayrı uygulanır. Farklı ÜH ler arasındaki bağımlılık ilişkileri, ÜH leri birleştiren BÜH içinde tanımlanır. Şekil 2. Radar Elektronik Harp Ürün Hattı Bağımlılık Görünümü RadEH BÜH si Kesişim Alanı Servisleri Katmanında yer alan kütüphaneleri (ÜHDB) kullanır. RadEH ayrıca HASP, VERY ve Seyrüsefer ÜH lerini de kullanır. Bu ÜH ler Kesişim Alanı Servisleri Katmanında yer alan kütüphaneleri de kullanmaktadır. 3 117

Tablo 2. Ürün Hattı Bağımlılık Bakış Açısı Tablo 3.Ürün Hattı Konfigürasyon Bakış Açısı Bakış Açısı Öğesi Đsim Özet Öğeler Đlişkiler Kısıtlar Gösterim Tanım Ürün Hattı Bağımlılık Bakış Açısı Bu görünüm BÜH, ÜH ve ÜHDB arası bağımlılıkları tanımlar Bileşik Ürün Hattı (BÜH) diğer bileşik ürün hattı ve ürün hattı birimlerini barındıran bileşik yazılım ürün ailesi birimi Ürün Hattı (ÜH) tek bir yazılım ürün ailesi birimi Ürün Ailesi Dışındaki Birim (ÜHDB) yazılım ürün ailesi yaklaşımıyla geliştirilmeyen yazılım birimi Birimler arası bağımlılık ilişkisi Kesin kısıtlar olmamakla birlikte döngüsel bağımlılıklar, bir birimden fazla sayıda birime bağımlılık ya da uzun bağımlılık zincirleri ürünlerin artımsal bir şekilde ve alt-birimler olarak geliştirilmesini zorlaştırır. Öğeler Đlişkiler <<BÜH>> <Birim Đsmi> Bileşik Ürün Hattı <<ÜH>> <Birim Đsmi> Ürün Hattı Kullanır Örnek <<ÜH>> A Bakış Açısı Öğesi Đsim Özet Öğeler Đlişkiler Kısıtlar Tanım Ürün Hattı Konfigürasyon Bakış Açısı Bu bakış açısı ürün konfigürasyonlarını tanımlar Bileşik Ürün Hattı (BÜH) diğer bileşik ürün hattı ve ürün hattı birimlerini barındıran bileşik yazılım ürün ailesi birimi Ürün Hattı (ÜH) tek bir yazılım ürün ailesi birimi Ürün Ailesi Dışındaki Birim (ÜHDB) yazılım ürün ailesi yaklaşımıyla geliştirilmeyen yazılım birimi Zorunlu Bir varlığın seçimi alt seviyedeki varlığın seçimini zorunlu kılar Seçimli Bir varlığın seçimi alt seviyedeki varlığın seçimini tercihe bırakır Alternatif Bir varlığın seçimi alt seviyedeki yalnız bir varlığın seçimini zorunlu kılar, bir varlık seçili ise diğerleri seçilemez Veya Bir varlığın seçimi alt seviyedeki varlıklardan en az bir varlığın seçimini zorunlu kılar Zorunlu Kullanır Ürün ailesi varlıkları arasındaki zorunlu bağımlılıklar Seçimli Kullanır Ürün ailesi varlıkları arasındaki seçimli bağımlılıklar Bir ürün hattı birimi yalnızca bir üst seviye ürün hattı biriminin parçası olabilir BÜH birimlerinin ÜH ve ÜHDB parçaları olabilir ÜH birimlerinin yalnızca ÜHDB parçaları olabilir ÜHDB birimlerinin yalnızca ÜHDB parçaları olabilir <<ÜHDB>> <Birim Đsmi> <<ÜH>> B Ürün Hattı Dışındaki Birim A, B yi kullanır. 4.3 Ürün Hattı Konfigürasyon Bakış Açısı Ürün hattı ayrıştırma ve ürün hattı bağımlılık bakış açıları farklı yazılım birimleri arasındaki ayrışım ve bağımlılık noktalarını tanımlamaktadır. Ancak bu noktalar ürün konfigürasyonu için gerekli olan değişkenlik bilgisini içermez. Bu bilginin gösterimi amacıyla Tablo 3 te gösterilen Ürün Hattı Konfigürasyon Bakış Açısı tanımlanmıştır. Bu bakış açısına ait öğeler önceki bakış açılarıyla aynı olmakla birlikte ilişkiler farklı olarak değişken konfigürasyon bağımlılıklarını tanımlar. Bu ilişkiler, geleneksel yetenek modelleme yöntemiyle büyük benzerlikler göstermektedir. Ancak bu bakış açısında ilişkiler üst seviye yetenek soyutlama amacıyla değil, üst seviye ürün hattı birimlerinin (BÜH, ÜH, ÜHDB) tanımlanması amacıyla kullanılır. Ayrıca, kullanır ilişkisi yetenekler arasındaki işlevsel ilişkileri de gösterir. Bu bakış açısındaki ilişkilerin tanımında, yetenek modellemedeki geleneksel yapısal bağımlılıkları işlevsel bağımlılıklarla zenginleştiren Lee ve Kang ın [8] çalışmalarından esinlenilmiştir. Ürün hattı konfigürasyon bakış açısı tanımlanırken yapısal bağımlılık ilişkilerinin (zorunlu, alternatif, seçimli) yanında kullanır ilişkisinin de tanım içinde yer alması önemli görülmüştür. Gösterim Çalışma konusuyla ilgili örnek bir konfigürasyon görünümü Şekil 3 te verilmiştir. Bu görünümde bir REFoRM ürününün, bir RadEH, HabEH ya da Radar BÜH si ya da Kendini Koruma Suit ÜH sinden meydana geldiği görülmektedir. RadEH BÜH si veya ilişkisine sahip iki alternatif ÜH içerir; bu durumda ÜH lerden biri ya da her 4 118

ikisi de bir üründe yer alabilir. Şeklin alt kısmında Seyrüsefer, HASP ve VERY ÜH lerine ait kullanırlık ilişkisini göstermektedir. Bu ÜH ler diğer ÜH lerle ile birleşmeyip diğer ÜH ler tarafından kullanılır. sonra ilişkili ayrıştırma görünümü ve bağımlılık görünümü düzenlenmelidir. Şekil 5. Uygulama Ayrıştırma Görünümü Şekil 3. Şekil 1 deki Ayrıştırma Görünümü için Üst Seviye Konfigürasyon Görünümü RadarAlan1 den Seyrüsefer e olan ilişkide bir seçimli kullanım örneği yer almaktadır. Bu ilişki, ürün konfigürasyonu yapılırken Seyrüsefer in ihtiyaca gore alınabileceğini gösterir. Kullanır ilişkisi alternatif ve veya ilişkileri ile birlikte kullanılabilir. Şekil 4 te örnek bir uygulama konfigürasyon görünümü, Şekil 5 te ise bu konfigürasyon için ayrıştırma görünümü yer almaktadır. Şekil 4, Şekil 3 ten uyarlanmıştır. 4.4 Uygulama Mühendisliği Görünümleri Önceki bölümlerde tanımlanan bakış açıları, hem alan mühendisliği hem de uygulama mühendisliği aşamaları için kullanılabilecek mimari görünümleri belirtir. Şekil 6. Örnek Kullanırlık Görünümü Şekil 6 da yer alan örnek kullanılırlık görünümünde, REFoRM ürününün RadEH BÜH sine, RadEH in Radar ED ÜH sine, Radar EH nin Seyrüsefer, HASP ve VERY ÜH lerine ait ürünlerden meydana geldiği görülmektedir. Ayrıca, alt seviyedeki ÜH ler dört farklı ÜHDB yi de kullanmaktadır. Şekil 4. Uygulama Mühendisliğinde Seçilen Bir Ürün için Konfigürasyon Görünümü Uygulama mühendisliği sürecinde benzer mimari görünümler tanımlanmıştır. Geleneksel uygulama mühendisliğinde olduğu gibi tek bir ürünün çıkarılmasına odaklanılmıştır. Bu ürün çoklu ürün hattındaki ürünlerin bileşiminden meydana gelir. Konfigürasyonu tanımlamak için alan mühendisliğinde tanımlanan konfigürasyon görünümü kullanılır. Uygulama gereksinimlerine göre uygun bir konfigürasyon tanımlanmalıdır. Konfigürasyon tanımlandıktan 5. Alternatif Ayrışımların Analizi Görünümler hazırlanırken, alternatif ürün hattı ayrışımları olabilir. REFoRM sistemi oluşturulurken dört farklı alternatif belirlenmiştir: (1) sistemi tek ve bütün bir ürün hattı olarak tanımlamak, (2) sistemi dört farklı ürün hattı olarak tanımlamak, (3) Şekil 7 de gösterildiği gibi sadece uygulama alanlarını ürün hattı olarak tanımlamak ve (4) daha önce Şekil 1 de tanımlandığı şekilde bileşik bir ürün hattı tanımlamak. Alternatiflerin değerlendirilmesi amacıyla Aselsan tarafından aşağıdaki kriterlerin önemli olduğu değerlendirilmiştir: Alanların Ayrılması Aselsan çalışma organizasyonu, sınırları ve kapsamı belirlenmiş görev alanlarına uygun olarak kurulmuştur. Ürün hattı ayrıştırımı bu alanlarla uyumlu olmalı ve çalışma yapısını bozmamalıdır. Organizasyon Yönetimi Ürün hattı ayrıştırımı iş birimlerinin organizasyonu ve işlerin yönetimini kolaylaştırıcı nitelikte olmalıdır. 5 119

Başlangıç Đçin Đşgücünü Eniyilemek Ürün hattı ayrıştırımı en az işgücü harcanacak şekilde düzenlenmeli, yeni personel ihtiyacı doğmamalıdır. Yeniden Kullanımı Eniyilemek Sistem işlevselliği ve kapsamı belirlenmeli, farklı iş ürünlerinde birbirini kapsayan benzer yetenekler yer almamalıdır. Ürün Yönetimi Đş ürünlerine kolaylıkla yeni yetenekler eklenebilmeli, varolan yetenekler değiştirilebilmeli ya da çıkarılabilmelidir. Ürün hattı gelişimi yönetilebilir olmalıdır. Farklı Đş Birimlerindeki Ürünlerin Bileşimi Ürün hattı ayrıştırımı farklı iş birimlerinde üretilen ürünlerin bir arada kullanımına olanak sağlamalıdır. Değişkenlik Yönetimi Karmaşıklığı Büyük alanlarda ve büyük yetenek kümelerinde değişkenlik yönetimi karmaşıklığını yönetmek güçtür. Seçilen ürün hattı ayrıştırımı bu karmaşıklığın üstesinden gelebilecek nitelikte olmalıdır. Sistemi bileşik bir ürün hattı (BÜH) olarak tanımlamak (Şekil 1) hemen hemen tüm kriterler açısından olumlu olarak değerlendirilmiştir. Çoklu ürün hattı hiyerarşik bir yapı içerirken, alanların ve organizasyon yönetiminin ayrılmasına da olanak sağlar. Bu kriterlere göre dört farklı ürün hattı ayrıştırımının değerlendirilmesi Tablo 4 te verilmiştir. Yukarıda belirtilen tüm kriterlerin eşit ağırlıkta olduğu değerlendirilmiştir. Her kriter için değerlendirme ölçütü --, -, +-, + ve ++ değerlerini içerir. Değerler çok kötüden çok iyiye doğru tanımlanmıştır. Alternatiflere ilişkin değerlendirmeler aşağıda yer almaktadır. Tablo 4 te görüldüğü üzere sistemi tek bir ürün hattı olarak tanımlamak karmaşıklık yönetimi ve büyük ürün hattındaki organizasyon yönetiminin güçlüğü açısından tercih edilen bir yöntem değildir. Ayrıca, Görev Alanı Uygulamaları katmanında geliştirilen ürünler farklı bölümlerdeki personelin çalışmalarıyla ortaya çıkmaktadır. Farklı organizasyonlardaki kişilerin bir arada ve ortak bir ürün hattı için çalıştırılması yönetim açısından olası değildir. Öte yandan, bu alternatif işlevsel yeteneklerin birbirini içermediği yetenek kümelerinin hazırlanmasına olanak sağlayacağı ve bu nedenle işgücü kullanımını iyileştireceği için olumlu olarak değerlendirilebilir. Bu alternatifin ürün yönetimi ve yeni ürünlerin oluşturulması açısından da fayda sağlayacağı değerlendirilmiştir. Đkinci alternatif sistemi dört farklı ürün hattına ayrıştırmak olarak belirlenmiştir. Dört farklı Görev Alanı Uygulaması alanı için, alanlara özgü ürün hatlarının belirlenmesi bu alternatifin olumlu bir özelliğidir. Organizasyon yönetimi de farklı bölümler için, alan bazında ayrılacağı için, merkezi yönetim karmaşıklığı olmayacaktır. Ürün yönetimi kolaylaşacak, ancak farklı ürün hatlarındaki ürünlerin birleştirilmesinde güçlükler yaşanacaktır. Ayrıca, bu alternatifte, farklı alanlardaki benzer ihtiyaçlar nedeniyle aynı yetenekler birkaç ürün hattında gerçeklenecek ve bu nedenle işgücü kullanım verimi düşecektir. Sonuç olarak bu alternatifin diğerlerine göre daha fazla işgücü ihtiyacı olacağı değerlendirilmiştir. Üçüncü alternatif (Şekil 7) Görev Alanı Uygulamalarındaki dört alan için dört farklı ürün hattı ile birlikte tüm alanlarda ortak olan işlevlerin yer alacağı kütüphaneleri içeren bir platform katmanı (UA ÜH) olarak ayrıştırmaktır. Đlk dört kriter için bu alternatif ikinci alternatifle benzer görülmektedir. Đkinci alternatiften farklı olarak bu alternatif ürün yönetimi için uygun görülmemiştir. Bazı kritik alanların ürün hattı olarak geliştirilmeyip ürün hattı dışı birim olarak değerlendirilebiliyor olması bu uygunsuzluğun nedeni olarak gösterilebilir. Bu durumda ürün birleştiriminde sıkıntılar yaşanacaktır. Bu alternatif değişkenlik yönetimi karmaşıklığı açısından da ikinci alternatifle benzerlikler göstermektedir. Bazı işlevsel yetenekler kütüphaneler içinde yer alacağı için dört alan içindeki değişkenlik daha düşük olurken, yeni değişkenlikleri tanımlamak güçleşecektir. Şekil 7. Görev Alanı Uygulamaları için Dört Farklı ve Bağımsız Ürün Hattını (UA ÜH) Tanımlayan Örnek Ürün Hattı Ayrıştırma Görünümü Kesişen işlevsellikler azaltılabilir ya da önlenebilir. Hiyerarşik ve bileşik yapısı nedeniyle yeni ürünlerin geliştirimini destekler. Bu seçeneğe ilişkin tek nötr sonuç işgücü eniyilemede ortaya çıkmaktadır. Yeniden kullanım eniyilendiğinde işgücü kullanımı da eniyilenir, ancak ürün hatlarının yönetimine ilişkin işgücü, her bir alt ürün hattıyla bileşik ürün hatlarının yönetimi ayrı çabalar gerektirdiği için tek bir ürün hattına göre daha fazla işgücü ihtiyacı doğurmaktadır. Tablo 4. Ürün Hattı Ayrıştırımı Alternatiflerinin Değerlendirilmesi Matrisi Değerlendirme Kriteri Tek ÜH 4 ÜH UA ÜH BÜH Alanların Ayrılması (Alanlarla Uyumlu Olaran) - - + + + Organizasyon Yönetimi - - ++ ++ + - Đşgücü Eniyileme +(+) - - ++ Yeniden Kullanımın Eniyilenmesi (Kesişen Đşlevselliğin Azaltılması) ++ - - -(-) ++ Ürün Yönetimi +(+) + - - ++ Farklı Đş Birimlerindeki Ürünlerin Birleştirilmesi +(+) - - - ++ Değişkenlik Yönetimi Karmaşıklığı - - + + + 6 120

Tablo 4 te dört ürün hattı ve uygulama alanı ürün hatları tanımlamanın en kötü seçim alternatifleri olduğu görülmektedir. Şaşırtıcı olarak tek ürün hattı yaklaşımının beklenenden fazla sayıda kriter için olumlu değerlendirildiği görülmüştür. Paydaşlarla dikkatli bir inceleme ve değerlendirme sonucu Aselsan için en olası alternatifin bileşik çoklu ürün hatları olduğu belirlenmiştir. Her alternatifin değerlendirilmesi yalnızca bu alternatiflerin daha önceki bölümlerde verilen mimari bakış açılarına uygun olarak modellenmesi sonrası mümkün olmuştur. Bu mimari gösterimlerin olmaması durumunda tartışmalar ve taslak çizimler ya da yetenek modelleme ile sonuç elde edilebileceği, bu yöntemlerin hiçbirinin mimari gösterimlerin belgelenmesi kadar açık ve etkili olamayacağı değerlendirilmiştir. 6. Đlişkili Çalışmalar III. bölümde belirtildiği şekilde, çoklu ürün hattı yaklaşımı pek çok araştırmacı tarafından ele alınmıştır. Ommering çoklu ürün hatlarını ifade eden ürün popülasyonları kavramını ortaya koymuştur [10], Koala bileşenleri adı verilen, gömülü sistemler için tasarlanan ortak bileşen modelini tanımlamıştır. Koala bileşenleri, daha küçük bileşenlerin, daha büyük ve karmaşık bileşenleri meydana getirmek üzere bir araya getirilmesiyle oluşur. Bu yaklaşım, farklı ürün hatlarında üretilen pek çok ürünün bir araya getirilerek, istenen daha büyük ve karmaşık ürünün oluşturulmasına benzemektedir. Ommering, esnek bileşen bileşimi sağlamak için, farklı birleştiriciler kullanılarak bileşenler arasında arayüz kuran ilişkilere odaklanmıştır. Bu makalede ise ayrı ayrı bileşenlerin değil, tüm yazılım ürün hatlarının oluşturulmasına odaklanılmıştır. [9] da van der Linden, Philips Medical görüntüleme sistemleri (PMS) için hazırlanan çoklu ürün ailesinin geliştirilmesini açıklamıştır. Farklı ürünler dünyanın pek çok yerinde geliştirildiği için pek çok ürün grubu için farklı ürün hatları yer almaktadır. Farklı ürün hatlarındaki ürünler pek çok farklı özellik taşısa da, pek çok benzer yazılım da bulunmaktadır. Bu yüzden, tüm PMS için kullanılacak bir görüntüleme platformu geliştirilmiştir. Platformun kendisi de bir ürün hattıdır. Philips içindeki farklı ürün grupları, farklı platform konfigürasyonlarını kullanır. Pek çok ürün grubu içinde, görüntüleme platformu üzerinde çalışan yazılım da yazılım ürün hatlarıyla üretilmiştir. Bu durum platforma yeni değişkenlik gerekleri getirmektedir. Bu çalışmadan farklı olarak Aselsan daki çalışmalar bir platformu tanımlamaz, farklı alanlardaki ürünleri tanımlamak üzere bir ÇÜH mimarisi oluşturarak ürünlerin hazırlanmasını sağlar. Pek çok araştırmacı, ihtiyaç duyulan ürün hatlarının altyükleniciler tarafından geliştirildiği ve idame ettirildiği durumların da varolduğunu belirtmiştir. Bu altyükleniciler birbirlerinin rakibi de olabilir. Alternatif altyüklenicilerin bulunması tek bir üreticiye bağımlı olunmasını engeller, ürün çeşitliliğini artırır. Alternatif üreticiler tarafından geliştirilen ürün hatları rakip ürün hatları olarak adlandırılır. Bu kapsamda Hartmann [5], yetenek modellerinin birleştirilmesinin kesişen yeteneklerin yönetilmesi nedeniyle güç olacağını, alternatif ürünlerin alternatif uygulamalarındaki yeteneklerin bir araya getirilmesi yaklaşımının çok doğru olmadığını belirtmiştir. Yetenek modellerini birleştirmenin getireceği sıkıntılardan kurtulmak amacıyla Altyükleniciye Özgü Yetenek Modelleri (AÖYM) ve Altyüklenici Bağımsız Yetenek Modelleri (ABYM) adında iki farklı yetenek modelinin üretilmesi yaklaşımını önermişlerdir. ABYM alternatif üreticilere ait bileşenlerin değişkenliklerini birleştirir, ayrıca AÖYM ve ABYM deki yeteneklerin ilişkilendirilebilmesi için kısıtlar tanımlanır. Aselsan çalışmaları kapsamında çoklu ürün hattı bileşimi üzerine odaklanılmıştır. Çalışmadaki her ürün hattı Aselsan tarafından geliştirilmiş, bu ürün hatları için herhangi bir alt yükleniciden bir yazılım ürünü alınmamıştır. Rosenmuller [13] bir yazılım ürün hattının diğer bir yazılım ürün hattına ait bir ürünü kullandığı bağımlı ürün hatlarını incelemiştir. Çalışmalarında, farklı şekilde konfigüre edilebilen pek çok ürün hattı ürününün bir arada kullanıldığı durumda, içerilen yetenek modeline ait kısıtların yeterli olmayacağını değerlendirmişlerdir. Somut örnekler arasındaki bağımlılıklar göz önüne alınmalıdır. Benzer şekilde Rosenmuller, varolan yazılım ürün hattı modellemesine, yazılım ürün hattı örneklerini ve bağımlılıklarını tanımlamayı sağlayan sınıf çizelgelerine dayalı bir eklenti yapmıştır. Araştırmacıların, birleştirme modelleri adını verdikleri, çoklu ürün hatlarının yarı-otomatik konfigürasyonu çalışmalarına ilişkin detaylar [12] de verilmiştir. Aselsan modelinde BÜH yaklaşımı benimsenmiş, ürün hatlarının hiyerarşik bir yapıda bir araya getirilmesiyle farklı alanlardaki ürünlerin ortaya çıkması sağlanmıştır. 7. Sonuçlar Bu makalede çoklu ürün hatlarının modellenmesi için mimari bakış açıları tanımlanmıştır. Tanımlanan bakış açıları ürün hattı ayrıştırma bakış açısı, ürün hattı bağımlılık bakış açısı ve ürün hattı konfigürasyon bakış açısı olarak isimlendirilmiştir. Bu bakış açıları Aselsan da devam eden, ürün hattı ayrıştırma çalışmalarında edinilen tecrübelere dayalı olarak tanımlanmıştır. Bu kapsamda, çoklu ürün hattını tanımlayan birden fazla farklı ürün hattının bir araya getirilmesini sağlayan mimari tasarım çalışmaları gerçeklenmiştir. Sistemi mimari görünümler üzerinden modellemeyi sağlayan en önemli motivasyonlar, bu yöntemin sistemin anlaşılmasını ve farklı paydaşların sistem üzerindeki değerlendirmeleri için iletişimi sağlaması ile sistemin geliştirilmesi için yol gösterici olmasıdır. Varolan mimari bakış açıları çoklu ürün hattı bileşimini desteklememekte, bu makalede bahsedilen işlevleri sağlamada kısıtlı kalmaktadır. Benzer şekilde, ürün hatları için mimari bakış açılarının tanımlanması tüm süreç için önemli bir adımdır. Mimari bakış açılarının, Aselsan da yapılan çalışmaların mimari gösterimleri için kullanımı örneklerle verilmiştir. Mimari gösterimler farklı ayrıştırma alternatiflerinin belirtimi ve analizi için de faydalı olmuştur. Mimari gösterimler temel alınarak, iç içe ürün hatlarının bir araya getirilmesiyle oluşan çoklu bir ürün hattı ayrıştırımı uygun bulunmuştur. 5. bölümde tartışılan alternatif ürün hattı mimari ayrışımları arasından BÜH nin seçilmesi üst seviye bir referans mimariyi ortaya çıkarmakta ve farklı alanlardaki ürünlerin bu mimari çerçeve altında hazırlanmasını zorunlu kılmaktadır. Bu durum, ürünlerin çerçeve mimariye uyumlu olmasını gerektirmekle birlikte, ÜH içindeki mimarilerde bir kısıt oluşturmamaktadır. Gelecekteki çalışmalarımız mimari gösterimleri destekleyen bir aracın geliştirilmesi, çoklu ürün hattı mimari gösterimleri üzerinde çalışmalar ve ayrıştırma alternatiflerinin sayısal analizini sağlayacak ölçümlerin tanımlanması üzerine odaklı olacaktır. 8. Teşekkür Levent Alkışlar, Baki Demirel, Hakime Koç, Gökhan Kahraman, Şafak Şeker ve Ümit Demir e Radar ve Elektronik Harp alanı ve ürün hattı mimarisi ile ilgili değerlendirmelere verdikleri destek ve katkılar nedeniyle teşekkür ederiz. Bu çalışma Radar Elektronik 7 121

Harp Sistemleri için Ürün Hattı Mühendisliği Çalışmaları kapsamında Aselsan ve Bilkent tarafından gerçekleştirilmiştir. 9. Kaynakça [1] M. Aoyama, K. Watanabe, Y. Nishio, and Y. Moriwaki: Embracing Requirements Variety for e-governments Based on Multiple Product-Lines Frameworks. Proceedings of the 11th IEEE International Requirements Engineering Conference, 2003. [2] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, P. Merson, R. Nord, J. Stafford. Documenting Software Architectures: Views and Beyond. Second Edition, Addison-Wesley: Reading, MA, 2011. [3] P. Clements, L. Northrop. Software Product Lines: Practices and Patterns. Boston, MA:Addison-Wesley, 2002. [4] http://en.wikipedia.org/wiki/electronic_warfare_support_measures, accessed January 2011. [5] H. Hartmann, T. Trew, A. Matsinger. Supplier independent feature modeling. in: SPLC 2009, IEEE Computer Society, pp. 191-200. [6] ISO/IEC, ISO/IEC 42010 Systems and Software Engineering -- Recommended Practice For Architectural Description Of Software- Intensive Systems, 2007. [7] C.W. Krueger, New Methods in Software Product Line Development. BigLever Software, Austin, TX; in Proc. of 10th Software Product Line Conference, 2006 [8] K. Lee, L.C. Kang. Feature Dependency Analysis for Product Line Component Design, in: J. Bosch and C. Krueger (Eds.): ICSR 2004, Springer LNCS 3107, pp. 69 85, 2004. [9] F. van der Linden, J. G. Wijnstra, Platform Engineering for the Medical Domain, Proceedings PFE4, Bilbao, pp. 224-237, October 2001. [10] R. van Ommering, Widening the Scope of Software Product Lines from Variation to Composition, proceeding of the Software Product Lines 2nd International Conference, SPLC 2, San Diego, CA, Aug 2002, Springer-Verlag LNCS 2379, p 328. [11] K. Pohl, G. Böckle, F. van der Linden. Software Product Line Engineering Foundations, Principles, and Techniques, Springer, 2005. [12] M. Rosenmüller and N. Siegmund. Automating the Configuration of Multi Software Product Lines. In Proceedings of the International Workshop on Variability Modelling of Softwareintensive Systems (VaMoS). Linz, Austria, Jan. 2010. [13] M. Rosenmüller, N. Siegmund, C. Kästner, and S. Saif ur Rahman. Modeling Dependent Software Product Lines. In GPCE Workshop on Modularization, Composition and Generative Techniques for Product Line Engineering (McGPLE), pp. 13-18., Oct. 2008. [14] K. Schmid, M. Verlage. The Economic Impact of Product Line Adoption and Evolution. IEEE Software, Vol. 19, No. 4, July/August 2002, 50-57. 8 122