Küresel Yazılım Geliştirme Projeleri İçin Alana Özgü Dil

Transkript

1 Küresel Yazılım Geliştirme Projeleri İçin Alana Özgü Dil Buğra Mehmet Yıldız Bedir Tekinerdoğan Bilgisayar Mühendisliği Bölümü, Bilkent Üniversitesi, Ankara e-posta: 2 e-posta: Özetçe Daha az maliyet, daha hızlı geliştirme gibi nedenlerden dolayı yazılım geliştirme yaklaşımı, son zamanlarda tek merkezli geliştirme yerine coğrafik olarak değişik yerlere dağıtılmış olan sitelerde, birden çok takım tarafından geliştirmeye kaymaktadır. Küresel olarak dağıtılmış olan bu takımlarla yapılan yazılım geliştirme yaklaşımına Küresel Yazılım Geliştirme(KYG) denilmektedir. KYG için uygun bir mimari tasarlamak, dağıtılmış takımların iletişim, koordinasyon ve kontrol gereksinimlerini karşılamak açısından önemlidir. Fakat bir KYG mimarisini tasarlamak, pek çok ayrıntıyı düşünmeyi gerektirir ve çoğu zaman kolay bir süreç değildir. Bu makalede, KYG uygulama mimarisinin oluşturulması için, bir KYG meta modeli ile alana özgü dil bir dil sunuyoruz. Meta model, ayrıntılı bir KYG literatürü taramasıyla ortaya çıkarıldı. Alana özgü dil, Eclipse eklentisi olan XText kullanılarak tanımlandı. Alana özgü dil ve araç değişik KYG projelerinin değişik mimari seçeneklerini değerlendirmek amacıyla kullanılabilir.. Giriş Bir sistemin yapısını veya yapılarını içeren yazılım mimarisi, sistemin parçalarını, o parçaların görünür özelliklerini ve birbirleriyle olan iletişimlerini içerir[5]. Erken tasarım kararlarını somutlaştırdığı ve bunun ardından gelen analiz, ayrıntılı tasarım ve uygulamayı etkilediği için, yazılım mimarisi tüm yazılım geliştirme sürecinde anahtar bir ürünü oluşturur[3]. Bu yüzden yazılım mimarisinin değişik paydaşlardan gelen sistem niteliklerini desteklemesi önemlidir. Bu niteliklerin sağlandığını garanti etmek için genel varsayım temel noktaların belirlenmesidir. Bu amaçla değişik mimari tasarım yöntemleri tanıtılmıştır. Yazılım mimarisi geniş çaplı ve karmaşık yazılımların geliştirmenin doğasında bulunan zorluklarla başa çıkmada temel rol oynar. Mimari tasarım alanındaki son 20 yıldaki araştırmalar sonucunda çeşitli teknikler ve yaklaşımlar ortaya çıkmıştır. Mimarinin değişik görünümlerini ifade etmek için çeşitli mimari modelleme yaklaşımları önerilmiştir. Ayrıca, mimariyi tam olarak oluşturulmadan analiz edebilmek için geniş bir yelpazede analiz yöntemleri sunulmuştur. Bu gelişmelere rağmen, güçlü bir mimari tasarım ortaya çıkarmak, çeşitli noktalar ve üst düzey soyutlamaya bağlı olarak halen zor bir iş olmaktadır. Mimari tasarım topluluğundaki yazılım mimarisi çabaları genellikle tek sistem mimarisi üzerine yoğunlaşmıştır. Bununla birlikte, dünyada yazılım geliştirmenin güncel durumuna baktığımızda şu anki eğilimin tek merkezli geliştirmeden küresel anlamda dağılmış bir geliştirmeye geçiş yaptığını görmekteyiz. Bu tür yazılım geliştirme literatürde dağılmış veya Küresel Yazılım Geliştirme (KYG) olarak adlandırılmaktadır. Küresel Yazılım Geliştirmede, bir projede çalışan takımlar dünyanın değişik coğrafi noktalarındaki değişik sitelerde etkinlik göstermektedir. Bu takımların yalnızca kodlama üzerinde değil aynı zamanda gereksinim idaresi, piyasa izleme, bakım veya test gibi yazılımın değişik alanlarında çalıştıklarını görmekteyiz. Küresel geliştirmenin yalnızca bir şirket tarafından yönlendirilebileceği gibi alt yükleniciler veya birden çok şirketin ortak çalışması gibi iş paylaşımı da yapılabilmektedir. Kar amacı güden küresel şirketler, açık kaynak yazılım geliştirici topluluklar KYG takımları olarak görülebilir. KYG yaklaşımı uygulanırken olumlu beklentileri vardır. Küresel olarak dağıtılmış takımlar güneşi takip et (follow the sun) yaklaşımı olarak da adlandırılan, 24 saat çalışma yapabilmektedirler. Örnek olarak, yer kürenin üzerinde karşı karşıya yer almakta olan iki takımın bulunduğu bir projede, bir takımın bulunduğu yerde gece iken diğer takım mesai saatleri içinde çalışmaktadır. 24 saat çalışmaya bağlı olarak ürünlerin daha erken çıkması da beklentiler arasındadır. Ayrıca, yaşamın daha ucuz olduğu ülkelerde geliştirme yaptırmak çıkan ürünün maliyetini de ciddi oranda azaltmaktadır. Şirketler değişik ülkelere yatırım yaparak daha geniş bir yelpazede yetenekli iş gücüne ulaşabilmektedir. Bütün bu nedenlerin gelecekte daha da güçleneceğini düşünürsek, ileride yazılım geliştirme alanında daha ileri bir küreselleşme görebileceğimizi söyleyebiliriz. Küresel Yazılım Geliştirme(KYG) için uygun bir mimari tasarlamak; dağıtılmış takımların iletişim, koordinasyon ve kontrol gereksinimlerini karşılamak açısından önemlidir. Fakat KYG topluluğu, bu alandaki sorunlara teknik yazılım mimarisi açısından daha az yoğunlaşmıştır. Bu makalede, KYG mimarına, küresel boyuttaki ilgileri karşılayacak olan bir mimari tasarlamada yardımcı olacak bir yaklaşım sunuyoruz. KYG uygulama mimarisini oluşturmak için bir KYG meta modeli tanımladık. Meta model ayrıntılı bir KYG literatürü taraması sonucu oluşturuldu. Meta modelin kullanımı için, daha sonra alana özgü bir dil tanımladık. GSDML adını verdiğimiz bu dil, meta modelden yazılı olarak örnekleme yapılabilmesini sağlıyor. Meta model ve alana özgü dil değişik KYG projelerinin değişik seçeneklerini değerlendirmek amacıyla kullanılabilir. Makalenin geri kalan kısmı şu şekilde düzenlendi: Bölüm 2 de KYG mimarisi ve alana özgü dillere ait anahtar noktalar anlatıldı. Bölüm 3 te KYG meta modeli tanıtıldı. KYG için tanımladığımız alana özgü dilin ayrıntıları Bölüm 4 te verildi. Bölüm 5 ilgili literatürü çalışmalarının gözden geçirilmesini 89

2 içeriyor ve makale Bölüm 6 de bulunan Sonuç bölümüyle tamamlanıyor. 2. KYG Kavramsal Mimari Çalışması 2.. Kavramsal Mimari Şekil de KYG sistemlerinin kavramsal mimarisi gösteriliyor. Bir KYG mimarisi, genel olarak üzerinde sistemin değişik alanlarında çalışan değişik takımların çalıştığı birçok siteden meydana gelmiştir. Bu takımlar arasında geliştirme/kodlama, test, yönetici veya koordinasyon birimleri gibi takımlar yer alabilir. Genellikle bir site belli bir süreçten sorumludur. Buna ek olarak, her sitenin kendi yerel veri depolama birimi bulunabilir. Veri Depolama Birimi ANAHTAR Veri Depolama Birimi Ürün Geliştirme si Kavramsal Katman Şekil : KYG Kavramsal Mimarisi INTERNET Veri Depolama Birimi Veri Depolama Birimi Bağlantı KYG tasarımında, dört adet önemli unsur sıralayabiliriz: Geliştirme: Belirli bir süreç izlenerek yapılan yazılım geliştirme etkinlikleridir. Gereksinim analizi, tasarım, uygulama ve test etkinliklerini kapsar. Her bir KYG sitesi genellikle bu etkinliklerden birisini yürütür. İletişim: içi ve siteler arası iletişim mekanizmalarıdır. İletişimde bulunmak isteyen değişik siteler, tipik olarak aralarında ortak bir iletişim protokolü kullanır. Koordinasyon: Gereksinimlere bağlı olarak, değişik sitelerdeki yazılım geliştirme etkinliklerinin koordinasyonudur. Koordinasyon değişik sitelerin iş akışlarını ve zaman çizelgelerini hizalamak için gereklidir. Değişik koordinasyon mekanizmalarını kullanarak geliştirmeyi optimize etmek önemli bir hedef olarak gösterilebilir. Kontrol: Geliştirme etkinliklerinin analizi, izlenmesi ve bu etkinliklere yol gösterilmesi için uygulanan düzenli kontrol mekanizmalarıdır. Yalnızca işlevsel gereksinimlerin yerine getirilmesinin değil, aynı zamanda kalitesel gereksinimlerinin hangilerinin ve ne kadarının karşılandığının kontrol edilmesini de kapsar. Aslında bu unsurların her biri derinlemesine araştırma gerektiriyor ve aynı zamanda KYG topluluğu tarafından oldukça tartışılmıştır. Bizim dikkat çekmek istediğimiz önemli nokta şu ki bu unsurların KYG ortamındaki dağılımı doğrudan KYG mimarisini etkiler. KYG için uygun bir mimari tasarlamaksa; dağıtılmış takımların iletişim, koordinasyon ve kontrol gereksinimlerini karşılamak açısından önemlidir. Fakat bir KYG mimarisini tasarlamak, pek çok ayrıntıyı düşünmeyi gerektirir ve çoğu zaman kolay bir süreç değildir. boyutu ve sayısı, veri saklama biçimi, izlenen süreçler, iletişim protokolleri gibi pek çok parametrenin uygun şekilde seçilmesi gerekir. Ne yazık ki, mimara bu mimariyi oluşturmada yardımcı olacak sistematik bir yaklaşım bulunmamaktadır Alana Özgü Dil Olarak KYG Mimari tasarım temel olarak bir sistemin değişik bakış açılarından modellenmesidir. Tarihsel olarak, modeller yazılım mühendisliğinde önemli bir yer tutmakta ve yazılım projelerinde geniş çapta kullanılmaktadır. Modelleme, öncelikle bir iletişim yolu, üretim sürecinin analizi ve yönlendirilmesi amacıyla kullanılmaktadır. Modeller doğaları ve kaliteleri açısından çeşitlilik gösterir ve bu nedenle literatürde değişik sınıflandırmalar önerilmiştir. Mellor[4] modelleri hassasiyet seviyelerine bağlı olarak üç sınıfa ayırıyor: Taslak (sketch), ayrıntılı plan (blueprint) ve çalıştırılabilir (executable). Mellor a göre, çalıştırılabilir bir model, belli bir alanda beklenen işlevleri üretebilecek her şeye sahip olan modeldir. Çalıştırılabilir modeller, diğer iki model sınıfındaki modellere göre daha üst düzeyde hassastır ve model derleyicileri tarafından yorumlanabilir. Benzer bir sınıflamayı Fowler[2]; Kavramsal (Conceptual) modeller, Tanımlayıcı (Specification) modeller ve Uygulama (Implementation) modelleri olarak yapıyor. Model güdümlü yazılım geliştirme alanındaki model kavramı, Mellor un çalıştırılabilir sınıfına soktuğu modeller olarak tanımlanabilir[4][8]. Model güdümlü yazılımda, modeller yalnızca belgeler olarak yer almaz, ayrıca daha rafine edilmiş veya koda dönüştürülebilecek çalıştırılabilir kod görevi görür. Bu yönüyle modeli yalnızca ayrıntılı bir plan olarak gören modele dayalı yazılım geliştirmeden ayrılır. Modellerin ifade edildiği diller meta modeller tarafından tanımlanabilir. Dolayısıyla, Bir model bir meta modelin örneğidir. veya Bir model bir meta modele uyar. denilebilir. Bir meta modelin kendisi de meta modelleri tanımlama dili olan bir meta meta modele uyar. Bu dillerin geliştirilmesi, kullanımı ve bakımı konusunda sistematik, disiplinli ve ölçülebilir bir yaklaşım uygulanması yazılım dil mühendisliği olarak adlandırılır[]. Meta modellerin uygun bir şekilde tanımlanması geçerli ve güçlü modellerin ortaya çıkarılmasında önemlidir. Hem yazılım dil mühendisliğinde[] hem de model güdümlü geliştirme alanlarında[], meta model şu unsurları içermelidir: Soyut Dilbilgisi (Abstract Syntax): Dilin kavramlarını içeren bir sözlüğü ve bu kavramların nasıl bir şekilde birleştirildiğinde anlamlı bir model çıkacağının kurallarını içerir. Somut Dilbilgisi (Concrete Syntax): Dilde modelleri oluşturmaya ve ifade etmeye yarayan gösterimleri tanımlar. Diller tarafından kullanılan genel olarak iki tür somut dilbilgisi vardır: yazılı dilbilgisi ve görsel dilbilgisi. Yazılı dilbilgisi, modellerin yazılı olarak yapılandırılmış bir biçimde tanımlanmasını sağlar. 90

3 Görsel dilbilgisi ise, modellerin şemalar halinde ifade edilmesine olanak tanır. İyi Biçim Kuralları (Well-formedness rules): Soyut dilbilgisi dahilinde ifade edilemeyen ek kısıtlama ve kuralları tanımlar. Anlamsallık (Static Semantics): Soyut dilbilgisindeki kavramların ve ilişkilerin anlamlarını anlatır. Dilin anlam kısmı doğal dillerden(türkçe, İngilizce, vb) yararlanılarak tanımlanabileceği gibi diğer resmi tanımlama dilleri kullanılarak da tanımlanabilir. 3. Küresel Yazılım Geliştirme İçin Meta Model KYG literatürüne dayanarak, bu alanda bulunan kavramları ve onların ilişkilerini içeren, alana özgü dil tanımlamasında kullanılacak olan bir KYG meta modeli tanımladık. Meta model geniş bir boyutta olduğu için altı meta model birimi(veya dil birimi) olarak bölmeyi uygun bulduk. Meta model birimlerinden her biri birbirlerine ilişkisel olarak yakın kavramları içeriyor ve değişik paydaşların beklentilerini karşılamayı hedefliyor. Bu meta model birimleri Konuşlandırma,, Veri, İletişim, ve Göç birimleridir. Bu birimlerin her birinin ayrıntılarını sonraki başlıklarda açıkladık. lar, bulundukları ülkelere ve içinde yaşadıkları toplumlara bağlı olarak değişik Sosyal Kültürlere sahip olabilirler. Benzer bir şekilde, ın geçmişinde beraber çalıştığı süreye bağlı olarak geliştirmiş olduğu bir İş Kültürü de vardır. ların konuşabildikleri Diller mevcuttur. Uzmanlık Alanı, ve kavramları kendi içlerinde hiyerarşik bir düzene sahip olabilir. Örneğin, bir Yazılım ı; Tasarım, Kodlama, Test ve Entegrasyon larından oluşabilir Birimi birimi, KYG de izlenen değişik türdeki süreçleri ifade etmeyle ilgilidir. Bu meta model birimi Şekil 3 te gösterilmiştir. içerir koordine eder sağlar Koordinasyon İşlev * 3.. Konuşlandırma Birimi Konuşlandırma birimi, bir KYG projesinde çalışan çeşitli takımların değişik sitelere konuşlandırılmasını ilgilendiriyor. Bu meta model birimi Şekil 2 de gösterilmiştir. kullanır üretir 0..* 0..* Veri Parçası ihtiyaç duyar Uzmanlık Alanı type tip Dil İş Kültürü Organizasyon konuşur sahiptir 0.. aittir is geçici temporary mi is sanal virtual mı * sahiptir sahiptir konuşlandırılmış Şekil 2: Konuşlandırma Birimi Uzmanlık Alanı Sosyal Kültür time zaman zone dilimi location konum Burada, yalnızca bu dil biriminin değil tüm KYG meta modelinin temel sınıfını oluşturuyor., Belli bir hedefi gerçekleştirmek amacıyla bir araya gelmiş bir grup insan olarak tanımlanabilir. ların Uzmanlık Alanları mevcuttur. işlevi bittikten sonra dağıtılacak şekilde, geçici olarak oluşturulmuş olabilir. bir üzerinde konuşlandırılmıştır. ise ın çalıştığı ülke, şehir, bina gibi herhangi bir yer olabilir. nin konum özelliği onun dünya üzerinde nerede yer aldığını göstermektedir. Zaman dilimi özelliği nin konumuna bağlı olarak hangi zaman dilimi içinde bulunduğunu ifade eder. KYG projesinde yer alan takımlar; ticari, alt yüklenici, açık kaynak geliştirme grupları gibi değişik türden Organizasyonlara ait olabilirler. * * Şekil 3: Birimi, Belirlenmiş olan birtakım hizmetleri sağlamak amacıyla izlenen planlanmış etkinlikler silsilesi olarak tanımlanabilir. lar lere belli hizmetleri sağlamak amacıyla katılırlar. Bu hizmetleri meta modelde İşlev olarak tanımlıyoruz. Bir İşlev, yazılım geliştirme süresince karşılanması gereken, belli Uzmanlık Alanları isteyen herhangi bir hizmet olabilir. Koordinasyon da ların etkinliklerinin koordine edilme İşlevi olarak görülebilir. Bir, belli İşlevleri sağlamak için Veri Parçaları kullanabilir veya üretebilir Veri Birimi Veri birimi, KYG verilerinin sahipliğini ve konuşlandırılmasını gösterme amacı taşır. Bu meta model birimi Şekil 4 te gösterilmiştir. 9

4 Dil 0..* sahiplenilmiş yer alır dilinde Veri Parçası boyut dijital mi boyut türü oluşturma tarihi son güncelleme tarihi depolanmış Veri Depolama Birimi dijital depolama formatında 0.. Asıl Format formatında 0.. Dijital Format depolayabilir depolayabilir arayan aranan 0..* Veri Parçası taşır hedefler İletişim tür resmi mi eşzamanlı mı kanal mı başlangıç zamanı bitiş zamanı önerilen aralık üzerinde gerçekleşir İletişim Platformu Şekil 4: Veri Birimi Bu birimin çekirdeğini Veri Parçası oluşturur. Veri Parçası; ayırt etmeksizin tüm veri tiplerini ifade eder. Örnek olarak, dijital, yazılı, geliştirmecinin bir kağıt parçasına not aldığı resmi olmayan bilgiler veya kaydedilmeyen telefon görüşmeleri gösterilebilir. Veri Parçasının boyut türü ile ölçeklendirilen bir boyutu vardır: 6 dakikalık ses kaydı, 2 gigabytelık dijital veri veya 20 sayfalık rapor gibi. Oluşturulma ve son güncelleme zamanı Veri Parçasının tarihsel bilgisini verir. Veri Parçasının daha önceden tanımlanmış olan(video, ses, yazı, resim veya karışık) veya kullanıcı tanımlı bir Asıl Formatı vardır. Eğer Veri Parçası dijitalse, Asıl Formata ek olarak Dijital Formata da sahip olur. Veri Parçası birden çok Dilde olabilir. Veri Parçası bir Veri Deposunda saklanır(eğer saklanan bir veriyse). Veri Deposu, gerçek hayatta bilgi saklayabilen herhangi bir obje olabilir. Örnek olarak, yazılı belgeler, ses kayıtlı diskler veya üzerine not alınmış bir kağıt parçası Veri Deposu olabilir. Veri Deposu bir veya birden çok Asıl Formatı saklayabilir ve dijital bilgi saklama özelliği varsa saklayabildiği Dijital Formatlar da mevcuttur. Veri Deposu bir tarafından sahiplenilir ve bir de veya dağıtık veri tabanları gibi birden çok de konuşlandırılmıştır İletişim Birimi İletişim birimi, lar arasındaki resmi ve resmi olmayan iletişim etkinliklerini ifade etmeyi hedefler. Bu meta model birimi Şekil 7 de gösterilmiştir. İletişim, İletişim Platformu üzerinden belli veya ler dahilinde gerçekleşir ve telefon görüşmesi veya elektronik posta gibi anlık olay bazında olabileceği gibi tartışma forumları gibi sürekli açık bir kanal yoluyla da olabilir. İletişimin türü, İletişimin hangi yolla olduğunu gösteriyor, örneğin telefon, elektronik posta veya bir toplantı sırasında yüz yüze. Önerilen zaman aralığı KYG ları için önemli bir özellik olmakta çünkü farklı zaman dilimlerinde bulunan takımlar arasındaki iletişim günün her anı mümkün olmayabilir. Önerilen zaman aralığı İletişimde bulunacak olan takımların günün hangi zaman aralığında görüşülmesinin mümkün olduğunu belirtiyor. Şekil 5: İletişim Birimi İletişim genel olarak iki taraflı gerçekleşmektedir. Arayan kısım İletişim etkinliğini başlatırken arayanın aradığı takım aranan olarak nitelendirilebilir. Elektronik posta yollayan bir kişi arayan unvanını alırken postayı alan kişi aranan unvanını alır. Birden çok arayanın olduğu durumlara örnek olarak video konferans gösterilebileceği gibi planlanmış bir toplantı gibi arayan ve arananın aynı taraf olduğu örnekler de mevcuttur. ların İletişimi sırasında Veri Parçaları taşınmaktadır Birimi birimi İşlev ve İletişimin sağlanması sırasında kullanılan araçların ayrıntılarını içermektedir. Birimi meta modeli Şekil 6 de görülebilir. İletişim Platformu kullanılır içerir kullanılır içerir İşlev Platformu Şekil 6: Birimi Dijital Format uyumludur Asıl Format işbirliğini destekler mi uyumludur Bir bir veya birden fazla Asıl Format ve Dijital Formatla uyumlu olabilir. Platform ilgili İşlevi veya İletişimi sağlamak amacıyla kullanılan ların tümü olarak algılanabilir. Amacına bağlı olarak İşlev Platformu ya da İletişim Platformu adını alır Göç Birimi Göç Birimi, KYG projesi içindeki ların bir den başka bir ye olan hareketlerini ifade etmeyle ilgilidir. Bu hareketler özellikle projenin baş ve son kısımlarında koordinasyonu sağlamayı amaçlar. İlgili meta model Şekil 7 de gösterilmiştir. 92

5 yapılır Göç tarih Veri Depolama Birimi 0..* taşır dahilinde kaynak hedef Şekil 7: Birimi Göç bir veya birden fazla tarafından bir den diğer ye belli bir tarihte gerçekleşir. Göç sırasında, lar yanlarında dijital depolayıcılar veya yazılı belgeler gibi Veri Depolayıcıları taşıyabilirler. Ayrıca bir Göç, belirlenmiş bir süreç dahilinde gerçekleşir. 4. Alana Özgü Dil KYG mimarına yardımcı olması amacıyla, bir önceki bölümde tanımlamış olduğumuz meta model için yazılı bir somut dilbilgisi tanımladık. Yazılı dilbilgisini tanımlarken araç olarak bir Eclipse eklentisi olan XText aracını kullandık. XText, Eclipse Metinsel Modelleme Çerçevesi (Textual Modeling Framework) projesi içinde tasarlanmış bir dil geliştirme çerçevesidir[20]. Dil tanımlandıktan sonra dili tam olarak inşa eder: Dil Java sanal makinesi üzerinde çalıştırılabilir ve Eclipse tabanlı Tümleşik Geliştirme Ortamı desteğini alabilir. Oluşturulan dil yine Eclipse eklentisi olarak yayımlanabilir. XText dilbilgisi tanımlarken Eclipse Modelleme Çerçevesi (EMF, Eclipse Modeling Framework) ile beraber çalışmaktadır. EMF, ECore adı verilen, modelleme anlamında yazılım alanında çok sık kullanılan, bir meta meta modeli kullanarak kullanıcının kendi meta modelini tanımlamasına izin vermektedir. Bu anlamda, XText i kullanarak dilbilgisi tanımlama işi, yazılı somut dilbilgisi içinde soyut dilbilgisi tanımlamaya karşılık gelmektedir. XText aracı tanımlanan dilin dilbilgisinden ECore modeli çıkarmaktadır. ECore modeli diğer EMF tabanlı araçlarla uyum açısından önem teşkil etmektedir. XText kullanarak tanımladığımız dilbilgisini de, meta modelde olduğu gibi altı birime ayrıldı. Örnek dil birimi olarak, Şekil 8 da bulunan Konuşlandırma birimini veriyoruz. Bu dil birimine kısaca GSDML (Global Software Deployment Modeling Language) adını verdik. Dili *.xtext uzantılı bir dosya içinde tanımladık. Şekil 8: Konuşlandırma Birimi İçin Dilbilgisi Şekilde vermiş olduğumuz dil kullandığımız aracın gereği olan Genişletilmiş Backus-Naur Formu benzeri bir ifade biçimiyle tanımlandı. Dilin ilk kuralı olarak GSDModel, dilin başlangıç noktasını işaret ediyor ve bir Konuşlandırma modeline karşılık geliyor. Modelin özellikleri olarak, modelin özgün tanımlayıcısı, adı, oluşturma ve son güncelleme tarihi bulunuyor. Bir Konuşlandırma modeli, kuralıyla ifade edilmiş leri içeriyor. Her, kendini tanımlayan özellikler dışında kendisine bağlı olan lerden ve kendi üzerinde çalışan takımlardan oluşuyor. lar, kuralıyla tanımlanıyor ve meta modelde bahsettiğimiz konuşulan Dil listesi, bağlı olduğu Organizasyon, Sosyal ve İş Kültürü listesi ve Uzmanlık Alanı listesi özelliklerine sahip bulunuyor. XText aracı yazılı dilbilgisinden ECore modeline geçiş yaparken tanımlanan her kural için bir sınıf tanımladığı için meta modelimizde bulunan her sınıfı yazılı dilbilgisinde bir kural olarak tanımlıyoruz. Örnek olarak içerisinde 5 olan bir KYG projesi düşünelim: Şirket A Türkiye de etkinlik gösteriyor olsun. Müşteri ilişkilerini ve gereksinim analizini İstanbul da, yazılımın tasarımını Ankara da gerçekleştirdiğini; yazılım geliştirme ve test işini de Çin de, Pekin de bulunan bir yazılım şirketi olan Şirket B ye vermiş olduğunu varsayalım. Bu biçimde tanımlanan projenin yazılı modelinin çıktısı, Şekil 9 da kısmi olarak görülebilir. 93

6 TÜRKİYE Türkiye ı (Şirket A) Uzmanlık: Gereksinim A., Mimari Tasarım Diller: Türkçe, İngilizce Sosyal Kültür: Türk Kültürü İş Kültürü: İş Kültürü, İş Kültürü 2 İstanbul Gereksinim Analizi ı Uzmanlık: Gereksinim İdaresi İş Kültürü: iş Kültürü Ankara Yazılım Mimarisi ı Uzmanlık: Mimari Tasarım İş Kültürü: İş Kültürü 2 İnternet Çin Şekil 9: Örnek Yazılı Model Bu oluşturduğumuz model, dilin adını uzantı olarak taşıyan Ornek Proje.gsdml dosyasında kayıtlı halde bulunuyor. GSDML dosyalarının görsel şekillere dönüştürülmesi için model güdümlü geliştirme teknikleri uyguladık. Uyguladığımız model dönüşüm akışı Şekil 0 de verilmiştir. Çin ı(şirket B) Uzmanlık: Java geliştirme,,yazılım Test Mühendisliği Diller: Çince, İngilizce Sosyal Kültür: Çin Kültürü İş Kültürü: İş Kültürü 3, İş Kültürü 4 Geliştirme ı Uzmanlık: Java Geliştirme İş Kültürü: İş Kültürü 3 Pekin Test ı Uzmanlık: Yazılım Test Mühendisliği İş Kültürü: İş Kültürü 4 GSD Meta Modeli (.xtext) uyar kullanır Dönüştürme Tanımı yürütür kullanır UML Konuşlandırma Meta Modeli uyar Anahtar Ata-çocuk ilişkisi GSD Modeli (.gsdml) okur Dönüştürme Motoru oluşturur Uygulama Mimarisi Şekil : Görsel Model Şekil 0: GSDML Modelinden UML Konuşlandırma Modeline Dönüştürme İşlemi Model dönüşümünün kaynağı olan GSDML dosyası, kullanıcının XText aracını kullanarak tanımladığı dilden oluşturduğu örnek modeldir. Hedef dil için de UML Konuşlandırma meta modeli (UML profili olarak) tanımladık. Dönüşüm tanımı, KYG meta model elementlerinden konuşlandırma modelinin elementlerine eşleştirme içeriyor. Bu eşleştirme bir Eclipse eklentisi[8] olarak tanımlandı ve görsel sunuş için Eclipse Graphical Modeling Framework (GMF)[9] den yararlandık. Dönüşüm tamamlanıp görsel sunuş çıktıktan sonra, kullanıcı görseldeki elementleri istediği gibi değiştirebilir. Bu dil örneği, sözünü ettiğimiz KYG projesi için uygulama mimarisini içermektedir. Aynı mimarinin görsel hali Şekil de bulunabilir. Sunduğumuz meta model birimleri üzerine tanımlamış olduğumuz alana özgü diller, ana amaç olarak meta modelin yazılı biçimde resmi anlamda kullanılmasını amaçlamaktadır. Tanımlanan dil, KYG mimarisini tasarlamakta mimara yardımcı olacaktır. Bununla beraber, dilin tek kullanıcı olarak KYG mimarı hedeflenmemiştir. Dil, yüksek seviye bir dil olarak tanımlanmış ve KYG alanında çalışan alan uzmanlarının da rahat bir şekilde kullanabileceği biçimde oluşturulmuştur. 5. İlgili Çalışmalar Literatürde KYG nin mimarisi alanında uğraşıldığını pek göremiyoruz. KYG topluluğu yoğunlukla uğraşılan alanların iletişim, koordinasyon ve kontrol konularındaki endişeleri gidermek yönünde olduğunu görüyoruz. Clerk[7] mimari kurallar adını verdiği kavramı KYG endişelerinin çözülmesinde kullanıldığından söz ediyor. Mimari kurallar, yazılım mimarisinin organizasyon içinde uyumlu olması gereken prensipler veya komutlar olarak tanımlanıyor. Yine aynı makalede zaman farkı ve coğrafi mesafe, kültür, takımlar arası iletişim ve ortak çalışma ile iş paylaşımı konuları KYG da yaşanan sıkıntıların dört ana başlığı olarak sıralanıyor. Her bir sıkıntı için olası çözümler sıralanıyor ve bu çözümlerin mimari kurallar olarak ne kadar ifade edilebileceği aktarılıyor. Clerk in bu çalışması, KYG yi yönlendirmek için ne tür mimari kuralların olması gerektiğine ışık tutuyor. Bizim çalışmamız bu işi tamamlayıcı bir çalışma olarak algılanabilir. Çalışmamızda beklenen yanıtlara bağlı olarak tasarım hareketleri atanıyor. Paydaşların beklentilerine göre mimariyi değişik görünümleri kullanarak modelleme ve belgeleme genel olarak izlenen bir yoldur [5][9][2][5]. Mimari görünüm sistemin bazı parçalarını ve onların ilişkilerini, belli bir amacı desteklemek amacıyla tasvir etme olarak tanımlanır. Birden çok mimari görünüm kullanmak, hedeflenen beklentileri ayırmak ve 94

7 dolayısıyla farklı paydaşların anlama, iletişim ve analiz ihtiyaçlarını karşılamaya yardımcı olur. Görünümler, bir görünümün nasıl uygulanacağını anlatan bakış açılarına uyar. Mimari bir çerçeve de bu bakış açılarını düzenler ve yapılandırır. Literatürde değişik mimari çerçeveler önerilmiştir. Örnek mimari çerçeveleri olarak Kruchten in 4+ görünüm modeli[2], Siemens in Dört görünüm modeli[0] ve Görünümler ve Ötesi (Views and Beyond, V&B) [6] yaklaşımı gösterilebilir. Çalışmamızda uygulama mimarisinin Konuşlandırma görünümünü çıkarttık. Konuşlandırma görünümümün, KYG nin çoğul karakterini göstermesi açısından oldukça yararlı bir görünüm olduğunu söyleyebiliriz. Bununla birlikte, Ayrışma veya Kullanım görünümleri gibi diğer görünümler de düşünebilirdik. Bu durumda, meta model örneğiyle hedef görünüm arasında bir eşleştirme tanımlamak gerekirdi. desteği, geliştirme ortamlarını daha işbirlikçi yapması açısından KYG alanındaki önemli zorluklardan biri olmuştur[6]. Booch ve Brown İşbirlikçi Geliştirme Ortamı(İGO) denilen (Collaborative Development Environment, CDE) bir kavram ortaya attılar. İGO, zaman veya mekan ayrımına bakılmaksınız, proje dahilinde, takımların özellikle birlikte bir işi tamamlamak için özellikle yürütülebilir teslimat hazırlamak amacıyla, tartışabilecekleri, beyin fırtınası yapabilecekleri, bilgi paylaşabilecekleri sanal bir ortam olarak tanımlanıyor[2]. KYG alanında İGO yu desteklemek amacıyla pek çok çalışma ortaya çıkarıldı. Collab.net[3], yapılandırma yönetimi, hata takip, görev idaresi ve tartışma ortamı destekçisi olarak ticari bir İGO uygulaması biçiminde üretildi. Spanjers[7] otomatik çoklu site içeren projelerde otomatik olarak süreç inşası ve testi yapan SoftFab adlı aracı tanıttı. Caroll[4], kodlamada birliktelik farkındalığını arttıran ve eşzamanlı iletişimi destekleyen Jazz adlı aracı üretti. Whitehead [9], araç desteği konusunda, yazılım alanında var olan işbirliği destekçisi araçların bir incelemesini yaptı. Bu incelemede, var olan araçları dört gruba ayırdı: Kullanılan modelleri ifade eden Modele dayalı işbirlikçi araçlar, destekçisi araçlar, geliştiricileri işin gidişatından haberdar eden ve dolayısıyla çakışmaları önleyen Farkındalık araçları ve son grup olarak veri ve kontrol uyumunu ve ortak çalışabilirliği destekleyen İşbirliği Altyapısı. İGO araçlarına duyulan açık ihtiyaca ve bu araçların kanıtlanmış yararlarına karşın, bu araçlar konusundaki çalışmalar geliştirmeden ziyade işbirliği konusuna yoğunlaşmıştır. Dahası, geliştirme konusundaki çalışmalar ortak kodlamaya yönelik çalışmalar olup mimari tasarım konusuna fazla değinmemiştir. Mimari tasarım konusunda daha fazla araştırmaya ihtiyaç duyulması bundan dolayı ortak bir kanıdır. Bizim yaklaşımımız ve üretmiş olduğumuz yöntemin İGO araçlarının KYG tasarımına eğilmesi konusundaki çalışmalardan olarak düşünülebilir. 6. Sonuç Küresel Yazılım Geliştirme ortamını kurulurken karşılaşılan pek çok sorun tespit edilmiştir. Literatür araştırmamız sonucunda gördük ki KYG nin iletişim, koordinasyon ve kontrol alanındaki sıkıntılar çalışma konusu olmuş fakat KYG mimarisi için yapılan çalışmalar azınlıkta kalmıştır. Bu makalemizde, KYG mimarisi alanına yoğunlaştık. Tek sistem için mimari tasarlamak zor olmasının yanında KYG mimarisi tasarlamak, dağıtılmış olarak bulunan KYG takımlarının iletişim, koordinasyon ve kontrol sorunları yüzünden tek sisteme göre daha zordur. Mimarın uygun bir KYG mimarisi tasarlamasına yardım etmeyi amaçlayan bir KYG meta modeli, literatür araştırmamız sonucu ortaya çıkardık. Bu meta model KYG mimarisinin önemli noktalarını içermektedir. Konuşlandırma, süreç, veri, iletişim, araç ve göç olmak üzere altı adet meta model birimi tanımladık. Her bir meta model birimi için, mimarın değişik KYG mimarileri tasarlamasına ve incelemesine imkan verecek olan alana özgü dil ürettik. Alana özgü dil tanımlarından UML (profil) modeli çıkarmayı sağlayacak olan model dönüştürme işlemlerini belirledik. Yapmış olduğumuz çalışmanın devamı olarak, sunduğumuz bu yaklaşımı endüstriyel alanda uygulamayı planlıyoruz. Ayrıca, çıkarılacak değişik KYG mimarilerinin kalite kriterlerine göre karşılaştırılıp değerlendirilmesi çalışmasını da düşünmekteyiz. 7. Kaynakça [] J. Bézivin. On the Unification Power of Models. Software and System Modeling (SoSym) 4(2):7-88, [2] G. Booch and A. Brown. Collaborative Development Environments. Advances in Computers Vol. 59, Academic Press, August, [3] [4] M. Carroll and S. Sprenkle. Coven: Brewing Better Collaboration through Software Configuration Management. ACM SIGSOFT Foundations of Software Engineering, pp , [5] L. Cheng, C. DeSouza, S. Hupfer, J. Patterson, S. Ross. Building Collaboration into IDEs. ACM Queue vol. no.9, 2004 [6] 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, 200. [7] V. Clerc, P. Lago, H. van Vliet. Global Software Development: Are Architectural Rules the Answer? In: Proc. of the 2nd International Conference on Global Software Engineering, pp IEEE Computer Society Press, Los Alamitos, [8] Eclipse official web site, accessed 20. [9] Eclipse Graphical Modeling Framework, accessed February 20. [0] C. Hofmeister, R. Nord, and D. Soni. Applied Software Architecture. Addison-Wesley, NJ, USA. [] A. Kleppe. Software Language Engineering: Creating Domain-Specific Languages Using Metamodels. Addison- Wesley Longman Publishing Co., Inc., Boston, [2] P. Kruchten. The 4+ View Model of Architecture. IEEE Software, 2(6):42 50, 995. [3] A.J. Lattanze. Architecting Software Intensive Systems: A Practitioner s Guide, Auerbach Publications, [4] S.J. Mellor, K. Scott, A. Uhl, D. Weise. MDA Distilled: Principle of Model Driven Architecture, Addison Wesley, Reading, 2004 [5] R. Nord, P. Clements, D. Emery, R. Hilliard. A Structured Approach for Reviewing Architecture Documentation, 95

8 Technical Note, CMU/SEI-2009-TN , SEI-CMU, [6] B. Sengupta, S. Chandra, V. Sinha. A research agenda for distributed software development, In Proceedings of the 28th international conference on Software engineering, pp , [7] H. Spanjers, Ter, B. Graaf, M. Lormans, D. Bendas, R. V. Solingen. Tool Support for Distributed Software Engineering, in Proc of: International Conference on Global Software Engineering, ICGSE '06., pp , [8] T. Stahl, M. Voelter. Model-Driven Software Development, Addison-Wesley, [9] J. Whitehead, Collaboration in Software Engineering: A Roadmap, In FOSE '07: 2007 Future of Software Engineering, pp , [20] XText official web site: accesses in 20. [2] M. Fowler, S. Scott, G. Booch. UML distilled, Object Oriented series, 79 p. Addison-Wesley, Reading,