Model Tabanlı, ARINC 653 Uyumlu Aviyonik Yazılım Geliştirme ve

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
[email protected]
[email protected]
Mustafa TUFANER
Turgay SENLET
Aselsan MGEO, Ankara
Department of Computer Science
Rutgers, The State University of New Jersey
[email protected]
[email protected]
Ö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.