Recep Ataş 1, Oya Kalıpsız 2

Transkript

1 Fırat Üniversitesi-Elazığ SERVİS TABANLI YAZILIM ÜRÜN HATTI MİMARİLERİ Recep Ataş 1, Oya Kalıpsız 2 1 Bilgisayar Mühendisliği Bölümü Yıldız Teknik Üniversitesi recepatas@gmail.com 2 Bilgisayar Mühendisliği Bölümü Yıldız Teknik Üniversitesi kalipsiz@yildiz.edu.tr ÖZET Yazılım geliştirme süreçlerini hızlı, düşük maliyetli ve kaliteli bir şekilde gerçekleştirebilmek için Yazılımın Yeniden Kullanımı alanında birçok yeni fikir tanımlanmıştır. Çalışmada son zamanlarda yeniden kullanım alanında bilinirliği artan yaklaşımlardan biri olan Yazılım Ürün Hattı Mimarilerinin kullanımının yararlarından ve uygulama geliştirme süreçlerinden bahsedilip bu yaklaşımın kurumsal uygulamalarda yeniden kullanımı artırmak için kullanımı gösterilmektedir. Aynı zamanda bu uygulamalardaki ortaklıkların ve değişkenliklerin yönetimi için Servis Tabanlı Mimari içeren bir Yazılım Ürün Hattı Mimarisi modeli sunulmuştur. Bu kapsamda geliştirilen açık kaynaklı bir Yazılım Ürün Hattı (Software Product Line - SPL) olan Graymound yazılım geliştirme aracı anlatılmıştır. Anahtar Kelimeler: Yazılımın Yeniden Kullanımı, Yazılım Mimarileri, Yazılım Ürün Hatları, Alan Mühendisliği, Servis Tabanlı Mimari 1. GİRİŞ Günümüzde bir yazılım sistemini oluşturan parçaların büyük bölümü sadece o yazılıma özgü değildir, birçok yazılım ürünü tarafından da kullanılmaktadır. Yazılım geliştirme süresince yapılan işleri tekrar etmemek için yazılım mühendisleri benzer yazılım sistemlerindeki ortak noktalarını yeniden kullanıma göre hazırlamak isterler. Böylelikle önceden geliştirilen yazılım varlıklarını sonraki uygulamalarda yeniden kullanarak hızlı, kaliteli ve düşük maliyetli uygulamalar elde etmiş olmayı amaçlamaktadırlar. Yazılımın Yeniden Kullanımı (YYK), yeni bir yazılım sistemi oluştururken önceden var olan kaynak kod başta olmak üzere, gereksinim, analiz, tasarım ve test durumları gibi yazılım varlıklarının tekrar kullanımıdır. Çoğu yazılım uygulamasında üçüncü parti bileşenler ve yazılım elemanları kullanılmaktadır. Yeniden kullanılabilirlik, bir yazılım elemanının yeniden kullanım olasılığını gösteren bir niteliktir. Yeniden kullanılabilir varlıklar, yeniden kullanılabilen bir yazılım veya yazılım bilgisi olabilir. Ezran a göre YYK, önceden oluşturulmuş bloklardan sistematik olarak yazılım geliştirme yapmaktır. Böylelikle uygulamalar arasındaki mimari ve gereksinimler faydalanılarak üretkenlik, kalite ve iş performansı konularında yarar sağlanabilir.[1] Yeniden kullanım ilk olarak geliştirme aşamasında mevcut yazılımların kullanımı ile başlamıştır. Yazılımın yeniden kullanılabilirliği konusunda yapılan çalışmalara bakıldığında 1960 lar alt rutinler, 1970 lerde modüller, 1980 lerde nesneler, son 20 yılda ise Nesneye Dayalı Programlama mantığı ile geliştirilen birçok teknik ve en son olarak Alan Mühendisliği ve Yazılım Ürün Hatlarının (Software Product Lines - SPL) bu kapsamda kullanıldığı görülmektedir[2]. YYK, organizasyonlar tarafından bir projenin belirli bir kısmında veya tamamında tercih edilebilmektedir. Yeniden kullanımın büyüklüğüne göre; Nesne veya metotların yeniden kullanımı, Yazılım öğelerinin yeniden kullanımı, Tüm uygulama sisteminin yeniden kullanımı, olarak sıralanabilir. [3] Uygulamanın yeniden kullanılması tüm uygulamayı içerir, yani uygulama farklı projelerde tamamıyla yeniden kullanılabilir. Burada incelen iki önemli yaklaşım vardır. İlki COTS ürün yeniden kullanımı, bu yaklaşıma örnek olarak elektronik ticaret uygulamalarında pos entegrasyonu verilebilir. İkincisi, özel bir içerik için uyarlanabilecek ve ayarlanabilecek belirli ortak özellikleri olan uygulamaları kapsayan Yazılım Ürün Hatlarıdır li yıllardan sonra YYK adına en farklı fikir, Yazılım Ürün Hatları kavramı, SPL, ile gelmiştir[4]. SPL, Alan Mühendisliği (Domain Engineering) veya diğer adıyla Product Line Engineering(PLE) başlığı altında incelenmektedir. PLE gerçeklenirken tüm ürün hattı için değişken ve ortak olan gereksinimler bir araya getirilerek yeniden kullanım arttırılması amaçlanır. Bu gereksinimler ve bunu kullanacak ürünler göz önüne alınarak geliştirilirler. SPL kullanımının birçok başarı hikâyesi mevcuttur. Bu başarı hikâyeleri SPL kullanımını artırmada ve başarı için önemli teknik ve stratejik bilgi vermektedirler. Bunlardan bazıları; Frank van der Linden den tarafından hazırlanan Philips Medical Systems, Rob van Ommering ve Yolanda van Dinther tarafından hazırlanan NXP GTV, Peter Toft tarafından hazırlanan HP Printers ürün hatlarıdır [5]. SPL ile ilgili olarak birçok örnek vaka incelemesi bulunmaktadır. Ülkemizde geliştirilen SPL örneklerinden Aurora yazılım geliştirme hattı Cybersoft firması tarafından geliştirilmiş, bankacılık programları, merkezi kayıt sistemleri, sigortacılık uygulamaları gibi birçok kurumsal uygulamada kullanılmıştır [6]. ASELSAN A.Ş. silah sistemlerinde kullandığı yazılımlar için bir ürün hattı geliştirmiştir[7]. Bu çalışmanın ilerleyen bölümlerinde anlatılacak araştırma ve uygulamanın SPL kullanılarak geliştirilen yazılım projelerini kapsamaktadır. Çalışmanın uygulama kısmında OBSS yazılım evi tarafından geliştirilmiş ve geliştirilmekte olan Graymound[12] mimarisi ve bunun kullanımı incelenmiştir. Çalışmasının 2. bölümünde yazılım yeniden kullanımında geçmişten bugüne kadar uygulanan yöntemlerden bahsedilecektir. 3. bölümde; bir yazılım ürün hattındaki süreçler anlatılacak ve yazılım ürün hatları için kabul edilen çerçeve aktarılacaktır. 4. bölümde; kurumsal web ve masaüstü uygulamalarda kullanılan Servis Tabanlı Mimari içeren bir 199

2 Elektrik-Elektronik ve Bilgisayar Sempozyumu 2011 ürün hattı mimari modeli incelenecektir. Son olarak bu konuda gelecekte yapılması planlanan işler ile ilgili bilgi verilecektir. 2. YENİDEN KULLANIM YAKLAŞIMLARI Yeniden kullanıma göre tasarlanan yazılımlarının ve yöntemlerinin sayısı artmaktadır. Açık kaynak program kütüphaneleri ve yazılımlar bu alanda önemli derecede yeniden kullanılabilir kod sağlamaktadır. Belirli bir uygulama tipinde alana-özgü uygulamaların sağladığı yapı ile her müşteri bu uygulamaları kendi gereksinimlerine göre özelleştirebilmektedir. Aynı zamanda bazı şirketlerin müşterilerine sağladıkları bileşenler bir yeniden kullanım yöntemidir. Web servis, XML, vb. standartlar birbirinden farklı istemcilerde, uygulamalarda çalışabilmeyi kolaylaştırmaktadır. Bunlar gibi daha birçok yöntem, teknoloji, yaklaşım yeniden kullanım için geliştirilmektedir. Yukarıdaki örneklerden görüleceği üzere yazılım yeniden kullanımı farklı seviyelerde ve büyüklüklerde olabilir. Kod seviyesinde yeniden kullanım; nesne ve fonksiyonun yeniden kullanımı; basit bir fonksiyonu yerine getiren ufak yazılım bileşenleridir. Örnek olarak matematiksel bir işlem yapan fonksiyon veya nesne sınıfı verilebilir. Bu yaklaşımda bu fonksiyonlar standart kütüphanelerin içinde yer alabilir ve bu kütüphanelerin yeniden kullanımı ile sağlanabilir. Bilesen seviyesinde; bir uygulamanın bileşenleri, alt sistemler olabileceği gibi basit nesneler de olabilir, başka uygulamalarda yeniden kullanılabilir. Tüm uygulamanın yeniden kullanımı; sadece kod seviyesinde değil tüm uygulama sisteminin başka teknolojiler veya çalışma ortamlarına uydurulması ya da uygulamalara göre farklılaştırabilmesi ile sağlanabilmektedir. Diğerlerine göre daha büyük oranda yeniden kullanım söz konusudur, bunun için yeniden kullanım sistematik olarak ele alınmalıdır. Ortak bir mimariden türeyen uygulama aileleri örnek verilebilir. C.R.U.I.S.E. e göre sistematik olarak yeniden kullanımın bir organizasyona faydaları şu şekilde sıralanabilir[8]: Yazılım Kalitesi; her yeniden kullanımda varsa hatalar düzeltileceğinden, sadece bir kere geliştirilmiş ve kullanılmış bir bileşene göre daha yüksektir. Üretkenlik; kazancı geliştirilen kodun daha az olmasından dolayı daha fazladır. Bu, aynı zamanda daha az test, analiz ve tasarım eforuna ihtiyaç duyulduğunu gösterir, toplam maliyeti düşürür. Güvenilirlik; daha önceden kullanılmış ve test edilmiş bileşenlerin kullanımı bir yazılımın güvenilirliğini arttırmaktadır. Efor Azaltma; geleneksel yazılım geliştirmedeki her aşamada geliştirme zamanında azalma görülmektedir. Gereksiz İş ve Geliştirme Zamanı; bir sistemin gereksinimi, mimarisi, kodları ile baştan gerçeklenmesidir. Yeniden kullanılabilir varlıklar ile bu gereksiz işlerden kurtulabilinir. Bir Ürünün Piyasaya Sürülme Süresi; bir yazılım sistemin başarılı olup olmadığının önemli göstergelerinden biridir. YYK ile bu süre azaltılabilir. Çalışan Sayısı; artan yazılım üretkenliğiyle daha küçük takımlarla ürünler geliştirilebilir. YYK bu avantajları sağladığı gibi iyi yönetilmezse bazı riskleri de beraberinde getirmektedir. Eğer yeniden kullanılan yazılımın kodları elimizde yoksa bakimi maliyetli olabilir. Araç desteği eksikliği, nesneye dayalı geliştirmede genelde bu problem değil, gömülü sistemlerde problem olabilir. Yeniden kullanılabilir bilesen geliştirme maliyeti yüksek olması ve bileşenlerin araştırılması, bulunması zaman alabilir[2] Yeniden Kullanım Yöntemleri Yazılım geliştirmenin başlangıcından günümüze kadar özellikle Nesneye Dayalı Programlamanın ortaya çıkmasıyla birlikte yeniden kullanım için birçok farklı yöntem geliştirilmiştir. Bir Yazılım Ürün Hattı mimarisi geliştirirken bu mevcut yöntemlerden faydalanılmaktadır. Bu yöntemlerden bazılarını şu şekilde sıralayabiliriz[3]; Yazılım Mimarileri (SOA, DSSA, vb), bir yazılım sisteminin yapısını, davranışını ve önemli özelliklerini göstermek için yüksek seviyeli soyutlama sağlar. Genelde yazılım mimarileri bir bileşen kümesi ve bu bileşenlerin entegrasyonu ve konfigürasyonundan oluşur. Tasarım Kalıpları Alana Özgü Diller ve Kod Üreteçleri Uygulama Çatılarını (Frameworks), yazılım sistemleri için kod seviyesinde soyutlama sağlayan sınıflar kümesidir. Servis Tabanlı Sistemler, sistemlerinin birbirlerine servisler ile bağlandığı mimarilerdir. Genel Kurumsal Planlama Programları, ERP Sınıf Kütüphaneleri İlgiye Dayalı Yazılım Geliştirme (Aspect Oriented Software Development); yazılıma kod seviyesinde esneklik ve yapılandırılabilirlik sağlamak için ilgileri ayırmayı amaçlar. Bir başka yeniden kullanım yöntemi olarak; belirli bir uygulama alanı içerisinde tekrar kullanılabilir yazılım bileşenleri geliştirmeye dayanan Alan Mühendisliği ve Yazılım Ürün Hatları çalışmanın geri kalanında sıkça bahsedilecektir. Burada önemli bir konu belirli bir yazılım sistemi için bu yöntemlerden hangisinin kullanımının en uygun olacağının belirlenmesidir. Genellikle bu geliştirilecek sistemin gereksinimlerine, teknolojilere ve o alandaki sahip olunan deneyime bağlıdır. 3. Yazılım Ürün Hatları Özellikle geliştirme zamanı düşürmesi ve üretkenlik arttırdığının gösterilmesiyle Yazılım Ürün Hattı yaklaşımının kullanımı yazılım geliştirmede kabul görmeye başlamıştır. SEI ye göre bir yazılım ürün hattı, belirli bir alan üzerinde düşünen veya belirli bir görevi yerine getiren ürünler kümesi olarak tanımlanır. Üretim alanında yeni bir yaklaşım değildir. Bugüne kadar otomotiv, uçak, bilgisayar, mobil cihazlar gibi birçok alanda bu ürün hatları geliştirilip kullanılmıştır. Ürünler arasındaki ortak noktalarını temel alan Yazılım Ürün Hatları, önemli ve geçerli bir yazılım geliştirme yaklaşımı olarak hızla yükselen bir yöntemdir. Yazılım Ürün Hattı, belirli bir pazara yönelik ortak ve yönetilmiş özellikleri olan yazılımların, ortak yazılım varlıklarının yeniden kullanımı ile geliştirildiği sistemler topluluğudur[10]. Bir Yazılım Ürün Hattı, genellikle bir Ürün Hattı Mimarisine sahiptir. Bir ürün hattı mimarisindeki ortak varlıklardan uygulamaya uygun olan bileşenler seçilip 200

3 Fırat Üniversitesi-Elazığ düzenlenerek yeni ürünler oluşturulur. Bunun için mimari gereken seviyede parametrik ve genişletilebilir olmalıdır. Her ürün bu referans mimariyi türeterek, bileşenleri yapılandırarak ve kendisine özgü kısımları geliştirerek kendi mimarisini oluşturur[11]. Şekil 1 de görüleceği üzere genel bir yazılım mimarisi tek bir yazılım sisteminin yapısını tanımlarken, bir ürün hattı mimarisi birbiriyle ilintili ürünlerin mimari yapılarını tanımlar. Şekil 1: Yazılım Ürün Hattı Mimarisi[5] Yazılım Ürün Hatları, uygulama çatılarına göre daha belirli alanlar üzerinde yeniden kullanımı sağlar. Uygulama çatıları genele hitap etmektedir ve sadece kod seviyesinde yeniden kullanım sağlarlar. Temelde, bir ürün hattı ana varlık geliştirme ve bu ana varlıklarla ürün geliştirmeyi içerdiği söylemiştik. Yazılım Ürün Hatlarında 3 temel aktivite bulunmaktadır[5]. Bunlar: Alan Mühendisliği; tekrar kullanılacak ve yapılandırılabilecek ana varlıkların ortaklıklarının ve değişkenliklerinin tanımlanmasını ve geliştirilmesini kapsar. Uygulama Mühendisliği; ana varlıklar kullanılarak ve yapılandırılarak ürünlerin geliştirilmesini kapsar. Yönetim; organizasyonun bu aktivite içindeki süreçleri yönetimini kapsar. Şekil 2 de Yazılım Ürün Hattı Mühendisliğinde süreçlerin birbirleriyle nasıl etkileşimde olduğu gösterilmektedir[7]. mühendisliği süresince tanımlanan alan için yeniden kullanılacak ana varlıklar geliştirilir. Ana varlıklar, yazılım ürün hattının temelini oluşturan yeniden kullanılabilir varlıklar ve kaynaklardır. Yazılım Ürün Hattının uygulanması ve bir yazılım ürün hattından ürün elde etmek için bu ana yazılım varlıkların sistematik olarak kullanılmasıdır. Referans Mimari; belirli bir alana özgü bileşenleri ve özellikleri barındıran, bu alan kapsamındaki ürünleri geliştirirken referans alınan mimaridir. Ana Varlık Geliştirme (Core Asset Development) nin amacı ürün hattına üretim yeteneği kazandırmaktır. Ortaklıkların ve değişkenliklerin tanımlanması, ürünlerin paylaştığı ortak yazılım varlıkların geliştirilmesini içerir. Bu aşamada, değişim noktaları tasarlanır ve her bir değişim noktasıyla ilişkili değişkenler gerçeklenir[14]. Değişkenlik, alan mühendisliği sırasında tanımlanır, uygulama mühendisliği sırasında uygun değişkenler seçilerek kullanılır. Değişim Noktası, ürünlerin nerelerde farklılaştığını belirtir. Bu noktalarda uygulama geliştirici bir karar vererek uygun değişkenlerden birini seçer. Her değişim noktası bir veya birden fazla değişkeni seçenek olarak sunar. Değişken, bir değişim noktasına karşılık gelen, ona uyan her bir seçeneğe, özelliğe değişken adı verilir. Bu aktivitenin sonucu olarak; yazılım bileşenleri, yeniden kullanılabilir ve ayarlanabilir gereksinimler, tasarımlar gibi yazılım varlıkları elde edilir Uygulama Mühendisliği Ürün geliştirme aktivitesi Alan Mühendisliği kapsamındaki ana varlık geliştirme aşamasının 3 çıktısına; ürün hattının kapsamı, ana varlıklar ve üretim planına bağlı olarak yapılır. Ayrıca ürüne özgü tanımlamaların ve geliştirmenin yapıldığı ürün tanımlama alt süreci bulunmaktadır. Ürün oluşturma aşamasında seçilen her bir bileşen, değişkenlik, ortaklık özellik olarak adlandırılır. Yazılım ana varlıkları kullanılarak yeni bir ürün oluşturulur. Ürüne özgü yazılım kısımları geliştirilir. Uygulama mühendisliği aşamasında, değişim noktalarında ürünün ihtiyacına göre belirli değişkenlere bağlanır. Uygulama Mühendisliği ile Alan Mühendisliği süreçleri arasında geri dönüşümlü bir akış vardır. Yazılım Ürün Hatları için genel olarak yeniden kullanım Şekil 3 de gösterilmektedir. Şekil 2. Yazılım Ürün Hattı Süreçlerinin birbirleriyle ilişkileri[7] 3.1. Alan Mühendisliği Alan; belirli bir uzmanlık alanındaki bilginin özelleştirilmiş halidir. Bir alanının kapsamı, belirli bir alanın içerisine hangi ürünlerin alınabileceğini gösterir. Alan Şekil 3. Alan ve Uygulama Geliştirme İlişkisi 201

4 Elektrik-Elektronik ve Bilgisayar Sempozyumu Değişkenliklerin Yönetimi Bir Yazılım Ürün Hattı mimarisinin yerine getirmesi gereken en önemli özellik belirli ortaklıkları olan ürünler arasındaki değişkenliğin yönetilmesidir. Bir yazılım ürün hattının ürünler arasındaki ortak varlıkları içermesi kadar ürünlerin farklılaştığı yerleri görüp buna göre bir mimari sunması da önemlidir. Ortaklıklar; ürün hattı kapsamındaki her ürün tarafından paylaşılan özellikler olarak tanımlanabilir. Değişkenlik, bir yazılım sistemini ürüne göre düzenleme özelliğidir. Alan mühendisliği sırasında tanımlanır, uygulama mühendisliği sırasında uygun değişkenler seçilerek kullanılır. Ürünler arasında farklılık gösteren özelliklere değişkenlik diyebiliriz. Değişkenlikler, değişim noktaları kullanılarak gerçeklenirler. Bir değişkenliğin, ürün hattının içerisindeki her üründe bulunması zorunlu değildir. Bu açıdan değişkenlikler Tablo 1 de gösterildiği gibi 4 farklı tipte olabilirler. Zorunlu Opsiyonel Alternatif Çoklu Alternatif Tablo 1: Değişkenlik Tipleri Her üründe bulunması gereken fonksiyonlar, özellikler Her üründe bulunması zorunlu değil Bir grup özellikten sadece bir tanesi seçilebiliyorsa, seçilenin tipi alternatiftir. Bir grup özellikten bir veya daha fazlası seçilebiliyorsa, seçilenleri tipi çoklu alternatiftir Alan mühendisliği alanında yapılan çalışmalardan yola çıkarak Yazılım Ürün Hatları için kullanılan mevcut değişkenlik mekanizmaları şunlardır. Kalıtım; sınıf tanımı sırasında, sınıfın tanımına göre gerçeklenmesi (örneğin Java da Interface implementation) Genişletilmesi; gereksinim sırasında, sınıfın genişletilmesi (örnek Java da extends) Sınıfın Kullanımı; gereksinim sırasında, bir sınıfın başka bir sınıfı kullanması Yapılandırma; çalışma zamanından hemen önce, bileşeni özelleştirmek için ayrı bir dosyadan bilgileri almak (XML, JavaBeans properties dosyası gibi) Parametre; bileşen gerçekleme sırasında, bir fonksiyonun parametrelerini bir sınıf olarak almak, (calculate(rule rule) gibi) Şablon Tanımlama, bileşen gerçekleme sırasında, bir sınıfın tipi belirli bir tanım dâhilinde olacak şekilde sayısız alt tipten oluşabilir. (Java daki Generics Kütüphanesi bunu sağlar Örnek: ExceptionHandler<Container>) Üretim, çalışma zamanı sırasında ve daha önce, kullanıcının girdiği değerlere göre tanımları üreten bir araç (Yapılandırma sihirbazları gibi) İlgiye Yönelik Programlama Tasarım kalıpları, örnek olarak Adapter kalıbı Özellik dosyaları Dinamik sınıf yükleme, yansıma (Java Reflection kütüphanesis) Ürün hattı mimarilerinde ortaklık ve değişkenliklerin yönetimi için bu yöntemler dışında Servis Tabanlı Mimari (SOA) kullanımı da birçok çalışmada incelenmiştir. 4. Servis Tabanlı Ürün Hattı Mimarisi: Graymound Günümüzde kurumlar, web üzerinden ulaşılabilen ve yazılım ekipleri tarafından yönetilebilen güvenli ve yüksek performanslı platformlara gerek duymaktadır. Yazılım mühendisleri teknik detaylar ve mevcut teknolojilerin getirdiği kısıt ve zorluk yerine uygulamanın iş mantığına odaklanmalıdır. Yöneticiler zaman ve kaynak planı yaparken beklenmeyen bir hata veya gecikmeyle karşılaşmamalıdır. Organizasyonların rekabet açısından önemli gördükleri bazı noktalarda büyük ölçekli karmaşık kurumsal yazılım sistemleri bir takım özellikler sahip olması gerekmektedir. Bu özellikleri sağlaması durumda üretkenlik ve yazılım geliştirme hızı artacaktır. Buna göre; Farklı uygulamalara model sağlayabilme, Sık değişen müşteri isteklerini hızlı bir şekilde gerçekleştirmesi, Veri gösterme, kaydetme işlemleri için parametrik bileşenler, Dokümantasyonun otomatik oluşturulması, Test durumlarının yeniden kullanımını, Benzer yapıdaki çok sayıda uygulamanın geliştirilmesini, sağlayacak bir mimariye ihtiyaç duyulmuştur. Kurumsal uygulamalarda aynı veri tabanı elemanı farklı istemciler tarafından farklı ara katmanlar ve kullanıcı ara yüzleri ile çağrılmaktadır. Örneğin, bir bankacılık uygulamasında hesap bilgilerini web tabanlı bir istemci ile göstermek için farklı bir yazılım, şirket içi masaüstü uygulaması tarafından gösterebilmek için farklı, web servisleri ile diğer uygulamalarla birlikte çalışabilmesi için başka bir yazılım gerekmektedir. Burada mevcut yeniden kullanım yöntemleriyle veri erişim katmanının yeniden kullanımı sağlanabilir. Ancak, daha hızlı ve kaliteli yazılım için ön yüz ve orta katmanların da yeniden kullanımı sağlanmalıdır. Çalışmada, Yazılım Ürün Hattı süreçleri bu soruna çözüm olarak geliştirilen Graymound[12] uygulama ailesi üzerinde incelenmiştir. Graymound, kolay, hızlı, güvenli, standartlara sahip vekaliteli büyük ölçekli J2EE TM kurumsal uygulamaları geliştirmek için hazırlanmış Java ve Servis tabanlı, zengin ara yüzü bulunan yazılım geliştirme çözümüdür. Günümüzde geliştirilen yazılım projelerinin birçoğunun teknik açıdan vizyonu; yapılan işlerin tekrar yapılmaması ve esnek olmalarıdır. Küçük projelerde dotnet ve J2EE gibi alt yapılar, projenin çoğu gereksinimini karşılamaktadır. Ancak, projenin biraz daha büyümesi durumunda bu alt yapılar yetersiz kalmakta ve tüm projede uygulanabilecek, projeye bazı standartlar getirebilecek, projeye özel bir alt yapı gereksinimi ortaya çıkmaktadır. Bu tür alt yapılar sundukları 202

5 Fırat Üniversitesi-Elazığ çeşitli özelliklerle; yazılım geliştirme hızını arttırmakta, geliştirilen yapıyı belirli bir kalıba oturtarak projedeki insan faktöründen kaynaklanan problemleri en aza indirmekte ve toplam maliyetleri düşürmektedir. Projeye özel alt yapıların tasarlanması iyi bir analiz, deneyim ve vizyon gerektiren bir konudur. Aşağıda sayacağımız özellikleri ile bir SPL örneği olan Graymound kullanılarak birçok kurumsal uygulama geliştirilmiş ve geliştirilmeye devam etmektedir. Şekil 4 de Eclipse IDE si üzerinde geliştirilen eklenti ile yazılım geliştirme süreçlerinin modellenmesi gösterilmektedir. Bu eklenti ile analist ve yazılım geliştiriciler gereksinim analiz, tasarım, gerçekleme ve test süreçleri, Alan Mühendisliği kapsamında hazırlanan ürün hattı varlıkları kullanılarak daha hızlı ve kolay bir şekilde tamamlanır. Araç desteği bir yazılım ürün hattının sağlaması gereken önemli yazılım varlıklarından biridir[5]. Gereksinim Analizi Tasarım & Geliştirme Test Şekil 4. Graymound Eclipse Eklentisi - Alana Özgü Modelleme Aracı 4.1. Alan Mühendisliği Aktiviteleri Alan Mühendisliği kapsamında Eclipse IDE si üzerinde bir eklenti geliştirilerek hem web hem masaüstü uygulamaları için kolay ve hızlı bir şekilde ara yüzler hazırlanmaktadır. Genel olarak Graymound mimarisinin alan kapsamı 4 tür istemci isteğini karşılayabilmektedir. Bu istekleri uygun çıktıları üretebilmek için 4 farklı özellik sağlanmıştır. Ürün geliştirmek için bunlardan biri seçilir. Tablo 2 de istemci ve ona karşılık gelen özellik yer almaktadır. Mühendisliği sürecinde ürün geliştirme süresini önemli ölçüde kısaltmaktadır Uygulama Mühendisliği Aktiviteleri Alan Mühendisliğinde geliştirilen ana varlıklar kullanım ile ürünler hızlı bir şekilde geliştirilebilmektedir. Graymound, öne sürdüğü SOA tabanlı, XML standartlı kullanıcı ara yüzü geliştirme ortamı ile platformdan bağımsız çalışan bir SPL çözümüdür. Eclipse IDE üzerine geliştirilen eklenti sayesinde bir SPL in sağlaması gereken geliştirme aracı hizmetini de vermektedir. Bu sayede kolay bir şekilde ekran ve orta katman tasarımı yapılabilmektedir Servis Tabanlı Mimari Servis Tabanlı Mimari, Service Oriented Architecture (SOA), ve SPL yazılım geliştirme yaklaşımları benzer amacı paylaşırlar. Her ikisi de organizasyonların varlıklarını ve yazılım geliştirmedeki olgunluklarını tekrar kullanmaları sağlar. Bu yaklaşımlar yeniden kullanımı aktifleştirerek üretkenlik artışı, düşük geliştirme maliyeti, yüksek güvenilirlik gibi bir üründen beklenilen özellikleri karşılamaktadırlar. Bu iki yaklaşımı birbirinden ayıracak olursak şöyle bir tanım yapılabilir. SOA: Değişen gereksinimlere hızlı bir şekilde cevap verebilmek için kurumsal çözümlerin toplanması, düzenlenmesi ve bakımını kolaylaştırır. SOA kullanılan bir uygulamada yeniden kullanılabilirlik üst seviyededir. Oluşturulan her servis farklı projelerde dahi olsa yeniden kullanılabilmektedir. İş gereksinimlerinde bir değişiklik olduğunda bu değişikliğin uygulama tarafındaki etkisi sadece bu serviste olur. Yani ilgili değişiklik sadece bu serviste yapılır ve bu servisi kullanan uygulamalar değişiklikten büyük oranda etkilenmez[13]. Şekil 5 de Graymound mimarisindeki katmanlardaki bileşenler ve Servis tabanlı mimari gösterilmektedir. Graymound ürün hattı mimarisinde ana varlık olarak servislerin gerçeklenmesini ve kullanımı sağlayan bir model sunulmuştur. Farklı kurumsal uygulamalar tarafından kullanılması sağlamak için geliştirme tarafındaki yazılım varlıklarının bir kısmı Servis Tabanlı Mimari kullanılarak gerçeklenmiştir. Böylelikle farklı uygulamalar tarafından bu servislerin yeniden kullanımı sağlanmaktadır. Servis gerçekleme, tanımlama ve kullanma için Graymound, geliştiricilerin işini kolaylaştıracak geliştirme aracı sunmaktadır. Şekil 4 de gösterilen geliştirme aracı üzerinde aynı zamanda servis gerçekleme ve tanımlama yapılabilmektedir. Tablo 2: İstemciye özgü özellikler İstemci Özellik Web HTML, JSon Masaüstü Java Swing Web Servis SOAP, SOAP2 Rapor JasperReport Hızlı bir şekilde hazırlanan ara yüz katmanı ve orta katman her ortamda çalışabilmektedir. Bu da Uygulama Şekil 5. Graymound Mimarisi 203

6 Elektrik-Elektronik ve Bilgisayar Sempozyumu 2011 Yazılım Ürün Hattı Mimarileri ile Servis Tabanlı Mimarinin birlikte kullanıldığı birçok çalışma olmuştur. Yeni bir Yazılım Ürün Hattı ve Servis Tabanlı Mimarinin birleştirilmesi çalışmasında anlatılan ürün hattında, servisler, ürün hattının sağladığı ortaklıkların ve değişkenliklerin yönetimi için kullanılmıştır[13]. Bu amaçlar doğrultusunda SOA ile SPL arasında bir bağ olduğu ve servislerin Yazılım Ürün Hattı mimarilerini desteklediği söylenebilir. 5. SONUÇLAR Yazılımın yeniden kullanımının hızlı ve kaliteli yazılım geliştirmek için önemli bir kavram olduğu kabul edilmektedir. Yazılım Ürün Hatları bu konu başlığındaki yeni yöntemlerden biridir. Yazılım Ürün Hattı mühendisliği yaklaşımı önemi artan ve son zamanlarda daha sık kullanılan bir yöntem olmuştur. Organizasyonlara getirdiği faydalar sayısal olarak incelendiğinde birden fazla ürün geliştirildiğinde geleneksel yöntemlere göre daha düşük maliyetli olduğu görülmüştür. Günümüzde kurumsal uygulamalarda yapının birbirine benzediği için benzer yöntemlerin kullanımının yanında maliyeti ve yazılım kalitesi daha iyi olan bu yaklaşımın kullanılmasının daha da yaygınlaşacağı düşünülmektedir. İleriki zamanlarda, geliştirilen yazılım ürün hattının kapsamı dahilinde mobil uygulamalar, teknoloji güncellemeleri, yeniden kullanılabilir analiz ve test durumlarının genişletilmesi gibi yeni özelliklerin eklenmesi, kullandığı değişkenlik mekanizmalarının yanına İlgiye Dayalı Yazılım geliştirme prensiplerinin eklenmesi planlanmaktadır. [11] J. Bosch. Design and Use of Software Architectures - Adopting and evolving a Product-Line Approach. Addison-Wesley, 2000 [12] Son Erişim: [13] Dongsu Kang, Doo-Kweon Baik, Bridging Software Product Lines and Service-Oriented Architectures for Service Identification using BPM and FM, 9th IEEE/ACIS International Conference on Computer and Information Science, 2010 [14] Linda Northrop, Introduction to Software Product Lines, International Software Product Line Conference Tutorials, 521, 522, 2010 [15] F. M. Medeiros, Eduardo Almeida, Silvio Romere de L. M., Designing a set of Service-Oriented Systems as a Softeare Product Line, 2010 Fourth Brazilian Symposium on Software Components, Architectures and Reuse, , IEEE, KAYNAKLAR [1] Ezran M.; Morisio, M.; Tully, C. Practical Software Reuse, Springer, 2002 [2] William B. Frakes and Kyo Kang, Software Reuse Research: Status and Future, IEEE Transactıons On Software Engıneerıng, 2005 [3] Ian Sommerville, Software Engineering Ninth Edititon, Pearson, 2010 [4] K. Pohl, G. Böckle, and F. v. d. Linden; Software Product Line Engineering: Foundations, Principles, and Techniques, Springer, Berlin Heidelberg New York, [5] Software Engineering Institute Software Product Line sayfası, index.cfm, Son Erişim: [6] Aurora Software Product Line, I. Altintas, M. Surav, O. Keskin, S. Cetin, 2nd National Software Engineering, Conference, Ankara-Turkey, 2005 [7] Evrim Kahraman, Tolga İpek, Barış İyidir, Semih Bilgen, Bileşen Tabanlı Yazılım Ürün Hattı Geliştirmeye Yönelik Alan Mühendisliği Çalışmaları, 4. Ulusal Yazılım Mühendisliği Sempozyumu, 2009 [8] Reuse in Software Engineering Group, C.R.U.I.S.E, Compenent Reuse in Software Engineering, 2008 [9] Jules White, Jaames J. Hill, Sumant Tambe, Aniruddha Gokhale, C. Schmidt. Improving Domain Specific Language Reuse with Software Product Line Techniques. IEEE, /09, 2009 [10] P. Clements, L. Northrop, Software product lines: practices and patterns, Addison-Wesley, Boston,