Model Tabanlı, ARINC 653 Uyumlu Aviyonik Yazılım Geliştirme ve
Transkript
Model Tabanlı, ARINC 653 Uyumlu Aviyonik Yazılım Geliştirme ve
Model Tabanlı, ARINC 653 Uyumlu Aviyonik Yazılım Geliştirme ve Bütünleştirme Alper Tolga KOCATAŞ Ünal DURMUŞ Aselsan MGEO, Ankara Aselsan MGEO, Ankara akocatas@mgeo.aselsan.com.tr udurmus@mgeo.aselsan.com.tr Mustafa TUFANER Turgay SENLET Aselsan MGEO, Ankara Department of Computer Science Rutgers, The State University of New Jersey mtufaner@mgeo.aselsan.com.tr tsenlet@cs.rutgers.edu Özet Model tabanlı yazılım geliştirme, geleneksel yazılım geliştirme yöntemlerine göre dokümantasyon, taşınabilirlik, görsel bütünleştirme, üst seviye model test araçları kullanımı gibi çeşitli kolaylıklar ve avantajlar sağlamaktadır. Bu bildirinin amacı, model tabanlı yazılım geliştirme yöntemini Aselsan MGEO 1 grubu bünyesinde geliştirilen emniyet kritik yazılım projelerine uygularken kazanılan deneyimleri paylaşmak ve bu süreçte karşılaşılan problemlerin çözümleri için geliştirilen yöntemleri sunmaktır. Bildiri kapsamında yer alacak olan yöntemlerin başında yazılım birimlerinin modellenmesi ile birlikte bu birimlerin hızlı ve doğru olarak bütünleştirilmesi için geliştirilen yöntemler gelmektedir. Sunulan yöntemler, emniyet kritik yazılım bileşenlerinin bağımsız olarak tasarlanması ve bütünleştirilmesi için izlenmesi gereken yöntemleri tanımlayan ARINC 2 653 [1] standardını desteklemekle birlikte, bu standartın detaylarından bağımsız olarak model geliştirme konusunda da çözümler sunmaktadır. Abstract Model driven development has advantages over traditional development methods in ease of documentation, portability, graphical integration and usage of high level model test tools. Purpose of this paper is to share the experiences gained and solutions developed to overcome problems that have been faced while applying model driven development in safety critical software projects in Aselsan MGEO division. Methods developed for rapid and correct integration of software components will be the major subject of this study. Besides describing the development of software compatible to ARINC 653 [1] standard, which specifies guidelines for independent design and integration of safety critical software components, methods are also presented on how to design software models independent of the details of ARINC 653 standard. 1. Giriş Model tabanlı yazılım geliştirme, “Model Driven Architecture” [2] ismiyle bilinen bir yazılım geliştirme yöntemidir ve geleneksel yazılım geliştirme yöntemlerine göre çeşitli avantajlar sağlamaktadır. OMG3 tanımına göre model, bir içerik kapsamında ve belirli bir bakış açısından bir sisteme ait olan işlev, yapı veya davranışın biçimsel olarak tanımlamasını yapar. Model tabanlı yazılım geliştirme, sistemin dokümantasyonu, analizi, tasarımı, mimarisi, kurulumu ve bakımı gibi işlerde modellerin birincil kaynak olarak kullanıldığı bir yazılım geliştirme yaklaşımına verilen isimdir [3]. Model tabanlı geliştirilen bir projede kullanılan yapısal ve davranışsal diyagramlar, yazılım bileşenlerinin anlaşılabilirliğini artırmakla beraber, doğal bir yoldan, güçlü ve anlaşılır dokümantasyon sağlamaktadır. Farklı bir kod üretim aracı kullanılarak, aynı modelden farklı platformlara yönelik kod üretilebildiği için, model tabanlı geliştirme taşınabilirlik açısından da avantaj sağlamaktadır. Otomatik test kodu ve test dokumanı üretimi de model tabanlı geliştirilen bir projede model üzerinde çalışan araçlar kullanılarak başarılabilir. Yazılım bileşenlerinin bütünleştirmesi söz konusu olduğunda model tabanlı geliştirme, model elemanlarını otomatik olarak birleştirebilen grafiksel araçların kullanımıyla değişikliklerin son ürüne yansıtılmasını hızlandırarak açık bir fayda sağlamaktadır [4][5]. Bunların yanında, model tabanlı yazılım geliştirme 1 Mikroelektronik, Güdüm ve Elektro-Optik 2 Aeronautical Radio Inc 3 OMG: Object Management Group yöntemlerini uygularken dikkat edilmesi gereken bazı önemli noktalar vardır. Zaman zaman, model tabanlı yazılım geliştirme araçlarının verimi artırmaktansa geliştirme sürecini yavaşlattığı düşünülmektedir [5][6]. Model tabanlı geliştirilmemiş ama kullanılması gereken eski projelerin model tabanlı geliştirilen bir projede kullanımı da başlı başına bir sorun teşkil etmektedir. Geleneksel yöntemlerle yazılmış kaynak kodlarından model üretebilen tersine mühendislik araçlarının başarılı olamadığı durumlar olabilir. Bu tip kodlardan tersine mühendislik araçlarıyla tüm kodu kapsayan bir model oluşturmaya çalışmaktansa, sadece arayüzleri modelleyerek ve kodun işlevsel kısımlarını olduğu gibi bırakarak tüm kodu soyut bir bilesen – bir kara kutu – olarak ana modele dahil etmek daha yararlı olabilmektedir. IBM Telelogic Rhapsody model tabanlı yazılım geliştirme aracı, Aselsan MGEO bünyesinde geliştirilen emniyet kritik yazılım projelerinde model tabanlı yazılım geliştirme ve sistem modellemesi amacıyla uzun bir süredir kullanılmaktadır. Bu bildirinin amacı, model tabanlı yazılım geliştirme yöntemini geliştirilen emniyet kritik yazılım projelerine uygularken kazanılan deneyimleri paylaşmak ve karşılaşılan problemler ile bu problemlerin çözümleri için geliştirilen yöntemleri sunmaktır. Bildiri kapsamında yer alacak olan yöntemlerin başında yazılım birimlerinin modellenmesi ile birlikte, hızlı ve doğru olarak bütünleştirilmesi için geliştirilen yöntemler gelmektedir. Güçlü bir bütünleştirme alt yapısı için modelleme aracı içerisinde sistem bütünleştirme bilgilerini tutma yeteneğine sahip bir bütünleştirme model şablonu oluşturulmuştur. Bu yeni bütünleştirme modelinin modelleme aracındaki gerçekleştirilmesi yazılıma eklenen yeni profiller, tipler ve bütünleştirme için gerekli olan bilgileri tutan model elemanları sayesinde sağlanmıştır. Bütünleştirme modelinde gerekli parametreler sistemin ihtiyaçlarına uygun olarak doldurulduktan sonra model üzerinde koşturulan “Vekil Oluşturucu” ve “Mesaj Yorumlayıcı Oluşturucu” otomatik model üretim araçları, model parametrelerini kullanarak var olan yazılım modelinde gereken değişiklikleri yapmakta ve bu sayede yazılım bileşenlerinde yapılan değişikliklerin son ürüne hızlı ve sorunsuz bir şekilde yansıtılmasını sağlamaktadır. Sunulan yöntemler, emniyet kritik yazılım bileşenlerinin bağımsız olarak tasarlanması ve bütünleştirilmesi için izlenmesi gereken yöntemleri tanımlayan ARINC 653 standardını desteklemenin yanı sıra, bu standartın detaylarından bağımsız olarak model geliştirme konusunda da çözümler sunmaktadır. Önerilen yöntemler arasında platformdan bağımsız model geliştirme için uygulanabilecek “paket değiştirme” tasarım örüntüsü de yer almaktadır. Söz konusu örüntü kullanılarak, platforma özel olan model ayrıntılar, platform bağımsız olan modelden ayrı tutulabilmektedir. Bu yöntemler ve kullanılan otomatik bütünleştirme araçları sayesinde, sistemin tüm bileşenleri yerine, bileşenlerin herhangi bir alt kümesini hedef donanım üzerinde test etmek mümkün olabilmektedir. 2. Aviyonik Yazılımlar ve ARINC 653 Standardı ARINC 653 standardı, tümleşik modüler aviyonik sistemlerde 1 aynı anda farklı emniyet seviyeleri gerektiren birden fazla uygulamanın 2 birbirinden bağımsız ve güvenli olarak koşabilmesi için uygulama yazılımları, işletim sistemi ve bilgisayar kaynakları arasında kurulması gereken iletişimi ve ortak ara yüzleri tanımlamaktadır (Bkz. Şekil 1). Şekil 1 - ARINC 653 uyumlu sistem yapısı ARINC 653 standardının tanımlamış olduğu ortak APEX3 arayüzü aşağıdaki avantajları sunmaktadır: Taşınabilirlik: APEX arayüzü programlama dilinden, işletim sisteminden ve platformdan bağımsız olduğundan, teorik olarak ARINC 653 uyumlu uygulama yazılımlarının taşınabilirliği oldukça fazladır. Tekrar Kullanılabilirlik ve Modülerlik: Donanımdan bağımsız APEX arayüzü sayesinde tümleşik modüler aviyonik sistemler için yazılmış olan uygulamaların tekrar kullanılabilirliği bu arayüzü desteklemeyen uygulamalara göre daha fazladır. Farklı Kritiklik Seviyesindeki Uygulamaların Tümleşik Çalışması: APEX arayüzünün en önemli amaçlarından birisi de farklı seviyede emniyet 1 “Tümleşik modüler aviyonik sistem” deyişi, “Integrated modular avionics system” yerine kullanılmıştır. 2 Burada kullanılan “uygulama” terimi ARINC 653 kavramlarından “bölüt”e (partition) karşılık gelir. 3 APEX: APPlication EXecutive, ARINC 653 standardının tanımladığı ortak arayüze verilen isimdir. gereksinimleri olan yazılımların aynı donanım üzerinde koşabilmesidir. APEX arayüzü, sistemin ilklendirilmesi ve uygulamaların sağlıklı bir şekilde çalışabilmesi için ihtiyaç duydukları kaynakları yapılandırma tabloları ile tanımlar. Bu tablolar sistem bütünleştiricisi tarafından XML dili kullanılarak düzenlenir. Burada kullanılan XML dosyasının yapısı, ARINC 653 destekleyen bütün yazılım geliştime ortamları tarafından desteklenmelidir. Sistemde kaç adet uygulamanın olacağı, uygulamaların hangi zaman dilimleri süresince çalışabilecekleri, hangi kanallardan ne türde (örnekleme/kuyruk) haberleşme yapacakları ve hafıza gereksinimleri yapılandırma tablosunda belirtilir. Ayrıca ARINC 653 standardında tanımlanmış olan, sistemde oluşabilecek hata durumlarının hangi seviyede ve hangi eylemlerle ele alınması gerektiğini tanımlayan “Health Monitor” yapılandırması da yapılandırma tablolarında yer alır. XML XML Yapılandırma XML Yapılandırma Tabloları Yapılandırma Tabloları Tabloları OS OS Đşletim Yapılandırma Yapılandırma Sistemi Dosyaları Dosyaları Yapılandırma Dosyaları Şekil 2 – Đşletim sisteminden bağımsız olan ARINC 653 Yapılandırma tabloları işletim sistemine özgü yapılandırma dosyalarına çevrilir. Bahsedilen XML yapılandırma tabloları, kullanılan ARINC 653 uyumlu yazılım geliştirme ortamının sunduğu bir araç tarafından işletim sistemine özel yapılandırma dosyalarına çevrilir. Bu aşamadaki çevrim otomatik olarak yapılabilse de, tümleşik modüler aviyonik sistemlerdeki uygulama sayısı arttıkça XML yapılandırma tablolarının elle oluşturulması da giderek içinden çıkılmaz bir karmaşıklık arz etmeye başlamaktadır. 3. ARINC 653 Uyumlu Yazılım Modeli ARINC 653 uyumlu bir yazılım geliştirmek için model tabanlı bir geliştirme aracı kullanmak şart değildir. Fakat model tabanlı geliştirme araçları kullanmanın, yazılım geliştirme sürecini kolaylaştırmak ve tasarımı anlaşılır kılmakla birlikte, sistemi oluşturan yazılım parçalarının bütünleştirmesi konusunda da birçok avantaj sağladığı görülmüştür [7][8]. ARINC 653 standardında bahsedilen ve birbirini olumsuz olarak etkilemeden aynı işlemci üzerinde çalışabilen uygulamalar farklı kritiklik seviyesine sahip olabilirler. Bu uygulamalar genellikle farklı yazılım grupları tarafından geliştirilir. Geliştirme sırasında paylaşılan bilgi uygulamalar arasında iletişimi yapılacak arayüzler ve tiplerden ibarettir. Uygulama grupları birbirlerinden bağımsız olarak çalışır ve her grup kendi uygulamasını geliştirir. Sistem bütünleştiricisinin görevi ise, geliştirilen uygulamaların aralarında belirledikleri arayüzleri kullanarak birbirleriyle ve sistemin diğer yazılım elemanları ile haberleşmesini sağlamaktır. Bu bağlamda, uygulama geliştiricileri ARINC 653 standartlarından ayrıntılı olarak haberdar olmak zorunda da değildir. Sonuçta ARINC 653 farklı uygulamaların birbirleriyle olan iletişimlerini ve çalışma zamanlarını belirler. Uygulama yazılımcıları kendi tasarımlarını ARINC 653 standardına dayanarak yapmamaya gayret etmelidirler. Bu noktada akla “ARINC 653 standardı zaten taşınabilirliği hedeflemektedir; o halde geliştirilen yazılımın ARINC 653 standardına sıkı sıkıya bağlı yazılmasında ne sakınca vardır?” sorusu gelebilir Bu sorunun cevabı ARINC 653 olmadan, daha basit ortamlarda yazılım bileşenlerinin kendi aralarındaki bilgi akışının doğrulanması gerektiğinde anlaşılmaktadır. Geliştirilen sistem çok büyük çaplı olabilir ve aralarında sıkı sıkıya iletişim gereksinimleri olan bazı uygulamalar ikili, üçlü olarak bütün sistemden yalıtılarak test edilmek istenilebilir. Hatta bu tip testler uygulamaların işlevsellik gereksinimlerini test etmek için gerçek zamanlı olmayan bir işletim sistemi üzerinde koşturulmak istenilebilir. Bu sebeplerden dolayı, uygulama yazılımlarının ARINC 653 gereksinimlerinden soyutlanarak geliştirilmesinde fayda vardır. Örneğin, Kullanıcı Arayüzü Yönetimi, Seyrüsefer Sistemi Yönetimi, Haberleşme Sistemi Yönetimi, Sistem Kontrol Yazılımı, Grafik Arayüzü Yönetimi ve bunun gibi birçok uygulamadan oluşan bir sistemde, kullanıcı arayüzü yönetimi ve haberleşme sistemi yönetimi uygulamaları sistemden bağımsız olarak aralarında ikili bir test yapmak isteyebilirler. Hatta bu testi gerçek zamanlı bir işletim sisteminin kullanıcı dostu olmayan hata ayıklama araçları yerine standart bir PC kullanarak daha görsel araçlarla yapmak isteyebilirler. Bu durumda, ARINC 653 standardının tanımladığı işlevleri standart PC üzerinde sağlayacak bir alt yapınız yoksa bile, bu iki uygulamayı tek bir uygulamaya indirgeyerek aralarında bir test yapmak mümkün olabilmektedir. Daha ileri giderek, ARINC 653 alt yapısının PC üzerinde “yeterince gerçekçi” bir şekilde benzetimi yapılabilir ve böylece bu uygulamalar hedef sistemde test edilebilir. 3.1 Vekil Sınıfların Kullanımı Uygulama yazılımlarını ARINC 653 alt yapısından soyutlamak için, uygulama yazılımları ve APEX arayüzü arasındaki veri iletişimini sağlayan vekil sınıfları kullanılır. Model tabanlı yazılım geliştirme araçlarının farklı yazılım bileşenlerini birbirinden soyutlamak için kullandığı teknikler zaten mevcuttur. Aselsan MGEO bünyesinde geliştirilmekte olan aviyonik yazılım projelerinde kullanılan Rhapsody model tabanlı geliştirme uygulaması, bu amaç için Kapı (Port) ismi verilen bir tasarım örüntüsü kullanmaktadır. Rhapsody tanımına göre kapı, bir sınıfın, içinde bulunduğu ortamla veya kendi içindeki alt sınıflarla etkileşimde bulunduğu bir noktadır. Kapılar, sınıfların içinde bulunduğu ortamlardan bağımsız olarak tanımlanmasını sağlarlar. Kapılar sayesinde sınıflar kendi içlerindeki detayları ortamlarından tamamen yalıtabilirler [9]. BKps BSnf ASnf ve BSnf, AKps ve «flow» IletisimAry AKps BKps üzerinden arayüzünü kullanarak IletisimAry haberleşir. ASnf IletisimAry Şekil 3 - Rhapsody Kapı tasarım örüntüsü Şekil 3’de Rhapsody Kapı’larına bir örnek verilmiştir. Burada BSnf ve ASnf isimli sınıflar aralarındaki bilgi alış verişi IletisimAry isimli bir arayüze dayandırılmaktadır. Bu sayede her iki sınıfın iç detayları diğerinden yalıtılmış olmaktadır. Ayrıca, her iki sınıf da diğerini değiştirmeye gerek kalmaksızın, IletisimAry arayüzünü destekleyen bir kapıya sahip olan bir başka sınıf ile değiştirilebilirler. CSnf DSnf CSnf ve DSnf, CSnf'in kendi içinde tuttuğu DSnf göstergeci ile haberleşir. 1 Şekil 4 - Kapilarin yerine "Association" kullanımı Şekil 4’te de CSnf ve DSnf birbirleri ile haberleşen iki sınıf olsun. Bu örnekte Kapı yerine Birliktelik 1 kullanılmıştır. Đki tasarım da aynı işi görmektedir, fakat Birliktelik kullanılan örnekte, CSnf ve DSnf birbirleriyle daha sıkı bir bağ kurmuş durumdadır. DSnf, başka bir sınıf ile değiştirilmek istenildiğinde, CSnf’ı etkilemeden bunu yapmak mümkün değildir. Bu nedenle, yazılım parçalarının tekrar kullanımını kolaylaştırmak için yazlımın parçaları arasındaki ilişkileri Kapı kullanarak tanımlamak idame etmesi ve tekrar kullanımı kolay yazılım birimleri oluşturmaktadır. Çünkü kapılar arasındaki bağlar, sınıflara değil, kapının kontratında belirlenmiş olan arayüzlere dayanmaktadır. arasındaki bağlantıyı koda dönüştürebilmektedir. Ancak farklı ARINC 653 uygulamalarının kapıları arasındaki bağlantıları doğrudan koda dönüştüremezler. Bu iletişim, ARINC 653 veri iletişim kurallarını destekleyen kapılar ile yapılmalıdır. Dolayısı ile farklı uygulamalar arasındaki iletişimi modellemek için model tabanlı geliştirme aracının iletişim modelini özelleştirmek gerekir. Rhapsody aracı, nesneye yönelik yazılım geliştirme kavramlarından kalıt2 kullanımını kendi içindeki model elemanlarına da aktarmıştır. Bu özellik kullanılarak, gereksinimleri karşılamayan model elemanlarının yerine, var olan model elemanlarından yeni model elemanları türetmek mümkündür. Ayrıca yeni tanımlanan model elemanları kendine özel bilgiler taşıyabilmektedir. Bu da normal kapılara ek olarak, ARINC 653 standardında yer alan örnekleme ve kuyruk kapılarının tanımlanmasına izin vermektedir. Bu kapılar da genel Rhapsody kapıları gibi belirli arayüzlerle uygulamalar arası iletişimi tanımlamakla birlikte, ayrıca ARINC 653 örnekleme ve kuyruk kapılarını tanımlamak için gerekli olan ek bilgileri içerirler. Buna benzer özelleştirme teknikleri kullanılarak, Rhapsody aracında, ARINC 653 standardındaki “System, Module, Partition, Sampling/Queuing Port, Process vs..” gibi tanımları destekleyecek yeni model elemanları tanımlanabilir. Bu model elemanları, ARINC 653 ile ilgili yapılandırma bilgilerinin tümünün yazılım modelinde tutulmasına olanak vermektedir. Bu model elemanlarının içerdiği bilgiler işlenerek ARINC 653 işlevlerini kullanan kapılar için kod üretilebilir. Bu amaç için, uygulama yazılımlarını birbirine bağlayan kapılar ve APEX arayüzü arasında bulunması gereken vekil sınıfları otomatik olarak Vekil Oluşturucu Aracı ile oluşturulmaktadır. Bu sayede yapılandırmada yapılan değişiklikler otomatik olarak son ürüne yansıtılabilmektedir. Vekil Oluşturucu Aracı, vekil sınıflarını oluştururken, ARINC 653 sistemini tanımlamak için gerekli olan XML yapılandırma tablolarını da otomatik olarak oluşturur. Böylece hazırlanması zaman alan ve hata olasılığı yüksek bu süreç de otomatik olarak yapılmış olur. Model tabanlı geliştirme araçlarının sağladığı kapılar aynı uygulama içerisinde çalışan yazılım parçaları 1 Birliktelik: Association 2 Kalıt: Inheritance SeyBlsSnf 1 KayBlsSnf Vekiller Arinc653 kapıları arasındaki iletişimi sağlar «BilesenNesnesi» 1 «BilesenNesnesi» Sey Ka SsKayMesajSonucKps Mesaj Yorumlayıcı KaySeyTusVerisiKAKps Mesaj Yorumlayıcı Vekil SsMesajSonucuKps Vekil KaySeyTusVerisiKGKps SsKaNoktaVeriKps Mesaj Yorumlayıcı Mesaj yorumlayıcılar Arinc653 kapıları ve bileşenler arasındaki mesajların çevrim işlerini yapar Vekil SeyKayNoktaVeriOGKps Vekil Mesaj Yorumlayıcı SsNoktaKps SeyKayNoktaVeriOAKps Şekil 5 - Uygulama yazılımları arasındaki haberleşmeyi sağlayan Vekil ve Mesaj Yorumlayıcı Nesneleri 3.2 Mesaj Yorumlayıcı Sınıflarının Kullanımı Uygulama yazılımlarının ARINC 653 standartlarını kullanmadan da aralarında haberleşebilmesi için, ARINC 653 detaylarından soyutlanmaları gerekir. APEX arayüzündeki işlevler basit olarak, örnekleme/kuyruk mesajı al/gönder şeklinde tanımlanmıştır. Uygulama yazılımları birbirleri ile olan iletişimlerini daha anlamlı işlev isimleri kullanarak yapmak isteyebilirler. Ayrıca kuyruk mesajı iletimini sağlamakla sorumlu bir ARINC 653 kapısından yollanan mesajlara kimlik numaraları atanarak, kuyruğa gelen her mesajın farklı şekilde yorumlanması sağlanabilir. Örneğin, Kullanıcı Arayüzü Yönetimi uygulamasından Seyrüsefer Sistemi Yönetimi uygulamasına giden periyodik mesajlar, Şekil 5’teki SsMesajSonucuKps kapısının kontratında birden çok işlev kullanılarak tanımlanabilir, SsMesajSonucuKps kontratında WayPointEkle() ve WayPointSil() mesajları içeren WayPointYonetimiAry gibi bir arayüz olsun. Öte yandan, ARINC 653 kapıları GonderAperiyodikMesaj() isimli yalnızca bir işlev içeren KuyrukGondericiAry isimli bir arayüz destekliyor olsun. Kullanıcı Arayüzü Yöneyimi uygulaması, SsMesajSonucuKps kapısını kullanarak duruma göre WayPointEkle() veya WayPointSil() mesajını Seyrüsefer Sistemi Yönetimi uygulamasına iletmek isteyebilir. Bu durumda Kullanıcı Arayüzü Yönetimi uygulaması tarafında WayPointYonetimiAry mesajlarını KuyrukGondericiAry mesajlarına, Seyrüsefer Sistemi Yönetimi uygulaması tarafında da tam tersi yönde çevrim yapacak sınıflara ihtiyaç duyulur. Bu sınıflara da mesaj yorumlayıcı sınıfları ismi verilmiştir. Vekil sınıfları gibi, mesaj yorumlayıcı sınıfları da geliştirilen bir araç kullanılarak otomatik üretilebilmektedir. Mesaj yorumlayıcı sınıfları sayesinde uygulamalar birbirleriyle haberleşmek için geliştirdiği arayüzleri APEX arayüzünden bağımsız olarak tanımlayabilirler. 4. Platform Bağımsız Model Geliştirme Tekrar kullanılabilirlik önemlidir ve yazılım geliştirme yöntemleri tekrar kullanılabilirliği artıracak şekilde uygulanmalıdır. Platform bağımsız yazılımların taşınması ve farklı platformlara en az çaba ile uyarlanabilmesi kolay olduğundan, tekrar kullanılabilirliği de fazladır. Ne var ki, gömülü sistemlerde olduğu gibi, geliştirilen yazılımın donanımla sıkı sıkıya bağlı olduğu durumlarda platform bağımsız yazılım üretmek hayli zordur. Gelecekte Java gibi platform bağımsız, sanal makineler üzerinde çalışan dillerin aviyonik yazılım alanında kullanımı yaygınlaştığında platform bağımsız yazılım geliştirmek şimdi olduğundan daha kolay olabilir. Böyle bir avantajın olmadığı durumlarda ise yazılımın platforma bağımlı kısımları, platform bağımsız olarak geliştirilebilecek kısımlardan ayrı tutulmalıdır. Platforma bağımlı kısımlar değişik platformlar için ayrı ayrı geliştirilebilir. Böylece yazılım birden çok platformu desteklemiş olur. Model tabanlı geliştirme araçları kullanılarak bu durumu sağlamak çok daha kolaydır. Bunu başarmak için yapılması gereken, platform bağımlı olan her yazılım bileşenini soyut olarak tanımlamak ve desteklenecek her bir platform için yazılım bileşeninin platforma bağımlı farklı sürümlerini geliştirmektir. 5. Tartışma Şekil 6 - Platform bağımlı SeriPortYoneticisiSnf sınıfının bir tane genel tanımı ile birlikte üç farklı platform için üç farklı sürümü vardır. Örneğin, Şekil 6’teki SeriPortYoneticisiSnf gibi platforma bağımlı olması gereken bir yazılım parçası için öncelikle SeriPortGenelPkt altında genel bir sınıf tanımlanır. Model içinde SeriPortYoneticisiSnf sınıfını kullanması gereken diğer sınıflar, SeriPortGenelPkt içindeki genel sınıfı kullanırlar. Aslında SeriPortGenelPkt içinde tanımlı olan SeriPortYoneticisiSnf sınıfı tamamen soyut bir sınıftır ve bunun için kod üretilmez1. Şekil 7 - Platform1 için üretilecek kodlar için kapsam seçiminde Genel paketle birlikte Platform1 için geliştirilen paket dahil edilir. Platform için kullanılacak yapılandırmalar oluşturulurken, Şekil 7’teki gibi, SeriPortGenelPkt ile birlikte Seri Port yazılımının platforma bağımlı paketi de seçilir. Bu yöntemin avantajı, desteklenen platformlar için yapılandırmalar oluşturulurken, yazılımın platform bağımsız kısmının değiştirilmesinin gerekmemesidir. 1 Modelleme aracında bu tip soyut model elemanlarını “Use as external” gibi özelliklerle tanımlayarak bunkar için kod üretilmemesi sağlanabilir. Model tabanlı yazılım geliştirme araçları kullanılarak yazılım geliştirme gereksinim, tasarım, kodlama ve bütünleştirme süreçleri aynı araç üzerinden yapılmakta ve son ürüne dönüşünceye kadar geliştirmenin bütün aşamaları aynı ortamdan takip edilebilmektedir. Yazılım modelleme araçlarına yapılan eklentiler ve geliştirilen özel araçlar ile yazılımın tamamının tek bir model üzerinden takip edilmesi sağlanmaktadır. Geliştirmenin farklı aşamalarında ihtiyaç duyulan testleri gerçekleştirmek için farklı olanaklar sağlanarak yazılımın çalışacağı son donanım hazır olmadan veya yazılım son halini almadan önce değişik seviyelerde testler gerçekleştirmek üzere alternatif olanaklar sağlanmaktadır. Ayrıca bu yöntemler, uygulama yazılımı geliştiricilerinin alt seviyede kullanılan haberleşme yöntemlerinden bağımsız olarak kodlama yapmalarını sağlamakta ve yazılımın idamesini kolaylaştırmaktadır. 6. Kaynaklar [1] Aeronautical Radio Inc., Arinc Specification 653-1, Avionics Application Software Standard Interface, 16 Ekim 2003. [2] Architecture Board ORMSC, Model Driven Architecture (MDA), Doküman No: ormsc/2001-07-01, 9 Haziran, 2001. [3] Frank Truyen (Cephas Consulting Corp), The Fast Guide to Model Driven Architecture, The Basics of Model Driven Architecture (MDA), (Whitepaper) Ocak 2006. [4] Bran Selic, The pragmatics of model-driven development, IEEE Software, 2003. [5] B Hailpern, P Tarr, Model-driven development: The good, the bad, and the ugly, IBM Systems Journal, 2006. [6] Scott W. Ambler, Agile Model Driven Development Is Good Enough, Point-Counterpoint article in IEEE Software, Eylül/Ekim 2003. [7] Pedro de la Camara, Maria del Mar Gallardo, Pedro Merino: Model Extraction for ARINC 653 based Avionics Software, Model Checking Software – Springer, 2008. [8] Julien Delange, Laurent Pautet, Alain Plantec, Mickael Kerboeuf, Frank Singhoff, Fabrice Kordon: Validate, simulate and implement ARINC653 systems, SIGAda '09: Proceedings of the ACM SIGAda annual international conference on Ada and related technologies, p 31-44, November 2009. [9] Telelogic, Rhapsody User Guide, revised for product release 7.2, 2008.