Behiye Dilara Erkenci Özge Ünver Bekir Bilge Voyvoda 1,2,3 Aydın yazı

Güvenlik-Kritik Sistemlerde Nesne Yönelimli Programlama
Behiye Dilara Erkenci¹ Özge Ünver² Bekir Bilge Voyvoda<sup>3

1,2,3</sup>Aydın Yazılım ve Elektronik Sanayi A.Ş. (AYESAŞ) ODTÜ İkizleri Ar-Ge Binası A-1Blok Kat 1

Teknokent-ODTÜ 06531 ANKARA

¹e-posta: [e-mail] ² e-posta: [e-mail]

³ e-posta: [e-mail]

Özetçe

Bu bildiride, güvenlik-kritik sistemlerdeki nesne yönelimli programlama(NYP) kullanımında dikkat edilmesi gereken noktalar anlatılmaktadır. Bu bildiri ile AYESAŞ, bir güvenlik-kritik sistem tipi olan aviyonik(hava elektroniği) sistemlerde NYP kullanımıyla ilgili deneyimini ulusal yazılım endüstrisine aktarmayı amaçlamaktadır. NYP, yazılım geliştirme alanında geçmişteki uygulamalara göre daha fazla esneklik ve bakım kolaylığı sunmaktadır; fakat bu avantajların yazılım güvenliği üzerinde birtakım olumsuz etkileri olabilmektedir. Bu bildiri, NYP’nin kısa bir tanımı ve güvenlik-kritik sistemlerdeki kullanımının anlatımıyla başlamaktadır. Daha sonra, alttipler, altsınıflar, metodların yeniden tanımlanması, bellek yönetimi ve ilklendirme gibi NYP’nin temel özellikleri güvenlik-kritik sistemler açısından incelenmekte ve bu özelliklerin yaratabileceği sorunlara getirilen çözüm önerileri sunulmaktadır.

1.Giriş

NYP, yazılımdan beklenen davranışı gerçekleştirmek için veri ve metodlar içeren nesneleri kullanan bir yazılım programlama tarzıdır. IEEE NYP’yi, bir sistem ya da yazılım modülünün nesneler ve bu nesneler arasındaki bağlantılarla ifade edildiği yazılım geliştirme tekniği olarak tanımlar [2]. NYP’nin temel kavramları; büyük programlar yazmayı kolaylaştıran soyutlama, programları değiştirmeyi ve korumayı kolaylaştıran saklama ve programları kolayca genişletilebilir kılan sınıf hiyerarşisidir [1].
NYP, kod geliştirme araçlarının çeşitliliği ve tekrar-kullanılabilirlik özelliği sayesinde günümüzde birçok geniş çaplı yazılım geliştirme projesinde kullanılmaktadır. Buna karşın, bugüne kadar aviyonik yazılım sistemlerinin çok azı NYP ile kodlanmıştır. Güvenlik-kritik sistemlerin tasarımında, daha çok ilgili sertifikasyon gerekliliklerini yerine getirdiği bilinen teknolojiler tercih edildiği için, yeni teknolojilerin bu sistemlerde uygulanması biraz daha gecikmeli olmaktadır. NYP’nin birçok projede maliyetleri düşürmesi ve teknik olarak sağlam bir altyapı sunmasının ispatlanmasıyla beraber, güvenlik-kritik sistem üreticileri de NYP kullanımını dikkate almaya başlamışlardır. Bu nedenle, gömülü ve güvenlik-kritik sistemlerde NYP kullanımı günümüzde gelişmekte olan bir disiplindir. Güvenlik-kritik sistem yazılımlarında, nesne yönelimli modelleme, analiz, tasarım, programlama, doğrulama/test gibi tekniklerin kullanımına olan ilgi gün geçtikçe artmaktadır.
Güvenlik-kritik sistemlerin kullanım onayının verilmesi için, sistemlerin kullanım alanlarına göre değişen standartlar geliştirilmiştir. Bu standartlardan biri olan RTCA DO-178B/EUROCAE ED-12B ("Software Considerations in Airborne systems and Equipment Certification"), aviyonik yazılımlarının onaylanma standardıdır [4, 5]. DO-178B/ED-12B standardı, NYP’nin yaygın bir şekilde kullanılmaya başlanmasından daha önce hazırlanmıştır. DO-178B/ED-12B’nin NYP ile geliştirilmiş sistemlere uygulanmasıyla ilgili henüz resmi bir kaynak olmadığı için, sertifikasyon konusunda birtakım belirsizlikler yaşanmaktadır. Bu bildiri; DO-178B/ED-12B kapsamında, NYP kullanılarak geliştirilen aviyonik sistem yazılımlarında karşılaşılabilecek sorunları ve ilgili çözüm önerilerini içermektedir.

2.AYESAŞ Hakkında

AYESAŞ, yüksek teknoloji gerektiren komuta kontrol haberleşme ve bilgi sistemleri alanında ulusal savunma sanayimizin kabiliyetlerini arttırmak üzere Milli Savunma Bakanlığımızın yönlendirmeleri ile 1990 yılında kurulmuştur. Geçen 17 yıllık sürede kuruluş misyonuna hizmet edecek şekilde ulusal hava savunma sistemimizin omurgasını teşkil eden C4I sistemi dahil olmak üzere birçok projede başarı ile yer almış; sistem mühendisliği, yazılım, donanım ve üretim kabiliyetlerini zenginleştirerek bugüne taşımıştır.
AYESAŞ’ın sahip olduğu başlıca kabiliyetler:

• C4I Sistemleri Tasarımı, Üretimi ve Depo Seviyesi Bakımı

• Radar Entegrasyonu

• Taktik Veri İletişimi

• Gerçek Zamanlı Yazılım Geliştirme

• Aviyonik Sistemler için Yazılım Geliştirme (DO-178B/ED-12B Uyumlu)

• Bağımsız Yazılım Doğrulama ve Geçerleme (IV&V) (DO-178B/ED-12B Uyumlu)

• Tersine Mühendislik (DO-178B/ED-12B Uyumlu)

• Elektronik ve Elektromekanik Sistem Tasarımı

• Elektronik ve Elektromekanik Üretim ve Birleştirme

• Sistem Mühendisliği ve Sistem Entegrasyonu

• Hava Platformları Kablaj Tasarımı ve Üretimi

• Elektronik Ekipmanlar İçin Güçlendirme (Ruggedization)

• Simülasyon Sistemleri

• Bilişim Teknolojileri ve Danışmanlığı
AYESAŞ’ın misyonuna kurulduğu ilk günden bu yana destek veren Yazılım Grubu, komuta kontrol, gerçek zamanlı yazılım, taktik veri iletişimi, aviyonik yazılımlar ve simülasyon sistemleri konularında deneyimli yaklaşık 100 kadar çalışanı ve 17 yıllık deneyimi ile askeri ve sivil sektöre ihtiyaca yönelik ürün ve hizmetler sunmaktadır. Yazılım Grubunun yazılım geliştirme süreçleri SEI CMMI 3 olgunluk seviyesindedir. Bunun yanısıra Yazılım Grubu, ISO 9001:2000 ve NATO AQAP-150 kalite belgelerine de sahiptir.
1999 yılından bu yana sürdürülen aviyonik yazılım projeleri sayesinde AYESAŞ güvenlik-kritik yazılım geliştirme ve doğrulama alanlarında önemli deneyim kazanmıştır. AYESAŞ DO-178B standardına uygun olarak 400 bin kod satırından fazla yazılımın geliştirilmesi ve/veya doğrulanmasında görev almıştır. Bunlardan birisi de, komple bir aviyonik sisteminin içinde yer alan “Moving Map” yazılımıdır. AYESAŞ’ın bu yazılımın geliştirilmesi sürecinde NYP’nin güvenlik-kritik sistemlerde kullanımına ilişkin edindiği tecrübe bu bildirinin yayınlanmasında önemli bir kaynak oluşturmuştur. “Moving Map”projesi de dahil olmak üzere AYESAŞ’ın geliştirdiği tüm DO-178B/ED-12B uyumluluğu gerektiren projelerdeki sertifikasyon otoritesi ABD’nin FAA (Federal Aviation Administration) kuruluşudur [4, 5].

3.Güvenlik-Kritik Sistemlerde NYP Kullanımında Dikkat Edilmesi Gereken Noktalar

Nesne yönelimli programlamanın güvenlik-kritik sistemlerde kullanımı, güvenlik ve sertifikasyon açısından birtakım zorluklar ortaya çıkarmıştır. DO-178B/ED-12B sertifikasyon gereksinimlerine uyumluluk konusundaki belirsizlikler, NYP’nin güvenlik-kritik sistemlerde kullanımının yaygınlaşmasına engel oluşturmaktadır.
NYP’nin güvenlik-kritik sistemlerde kullanımına olan ilginin artmasıyla FAA, NASA’nın (National Aeronautics and Space Administration) desteğiyle “Aviyonik Sistemlerde Nesne Yönelimli Teknoloji” adlı bir proje başlatmıştır [7]. Bu proje kapsamında, NYP’nin havacılık yazılımlarında kullanımında sorun oluşturabilecek kritik noktaları belirleyen ve bunların çözümü için birtakım yaklaşımlar sunan bir el kitabı yayınlanmıştır.
AYESAŞ “Moving Map” yazılımı, DO-178B/ED-12B sertifikasyonu gerektiren ve NYP kullanılarak geliştirilmiş bir yazılımdır. Bu projede, NYP’nin sertifikasyonu zorlaştıran unsurlarının ortadan kaldırılması için hazırlanmış özel bir tasarım ve kodlama standardı ve programlama dili olarak da gömülü C++ kullanılmıştır. Gömülü C++ derleyicisi, çoklu miras, şablon, kural dışı durum işleme gibi birtakım NYP özelliklerini tamamen kullanım dışı bırakmaktadır. Bu şekilde derleyicinin otomatik kod üretmesi engellenmiştir. Tasarım ve kodlama standardı kullanımıyla da NYP’nin bazı özelliklerinin yolaçabileceği olası problemlerin önlenmesi amaçlanmıştır.
Bu bölümde, NYP’nin güvenlik-kritik sistemlerde kullanımında dikkat edilmesi gereken noktalar ve AYESAŞ “Moving Map” yazılımında DO-178B/ED-12B sertifikasyonu gereklilikleri için uygulanmış bazı kurallar yer almaktadır.

3.1.Alt Tipler

NYP’nin yapıtaşlarından miras kullanımı ile, var olan soyut tiplerin davranışlarının genişletilmesi veya özelleştirilmesinin yanında, farklı davranış ve özellikler de eklenmiş yeni soyutlamalar yapılandırılır. Miras aynı zamanda, farklı nesnelerin genel bir bakış açısıyla değerlendirilebilmesine olanak tanır. Miras kullanılarak oluşturulmuş bir tipler hiyerarşisinde, her alt tipte var olan ortak özellikler, bu alt tiplerin oluşturulduğu ana tip(soyutlama) tarafından gerçeklenir.
Güvenlik-kritik sistemlerde NYP kullanımına ilişkin karşılaşılan problemlerden alt-tipler çerçevesinde değerlendirilebilecek olanı çok biçimlilik kullanımı ile sağlanan tip yerine konulabilirliğidir. Olası herhangi bir metod çağrısında, bu çağrının farklı alt tipler tarafından karşılanabilir olmasına, NYP’de tip yerine konulabilirliği başlığı altında değinilmektedir. Nesne yönelimli sistemlerde, sistemin beklediği A tipinden bir değer ile, bu A tipinden türetilmiş A’ tipi birbirinin yerine kullanılabilir. Güvenlik-kritik sistemler açısından dikkat edilmesi gereken nokta, uygunsuz veya yanlış alt tipler oluşturulmasının, farkedilmesi zor ve istenmeyen işlevsellikler doğurabilecek olmasıdır.
NYP’nin miras özelliğinin kullanımı(tekli miras veya çoklu miras), ana sınıflar ile bu sınıflardan miras alan alt sınıflar arasındaki uyumluluğa ilişkin problemler ortaya çıkarabilir. Liskov Yerine Koyma Prensibi alt tiplerin davranışlarını kısıtlayan bir yaklaşımla uygun olmayan alt tipler oluşturulmasının ve kullanımının önlenmesine dayanmaktadır [3]. Liskov Yerine Koyma Prensibi’ne göre, ana sınıfların referansını veya işaretçilerini kullanan metodlar, bu ana sınıflardan türetilen sınıflara ait objeleri tiplerinden bağımsız bir şekilde kullanabilmelidirler.
1988 yılında Bertrand Meyer tarafından ortaya konan “Design by Contract” tasarımında, bir sınıfa ait metodlar giriş gereksinimlerini ve çıkış durumlarını belirtmeleri şartıyla, yürütülebilmeleri için gerekli ön koşulların sağlanması durumunda, çıkış durumlarının doğruluğunu garanti ederler. “Design by Contract” sınıfların tüm metodlarına uygulanabilir olmakla beraber, ana sınıfların tüm sanal metodlarıyla, bu metodları gerçekleyen tüm alt sınıflarda uygulanmalıdır [6].
AYESAŞ “Moving Map” yazılımı kodlama standardı, yazılımın Liskov Yerine Koyma Prensibi ve “Design by Contract” ile uyumlu olmasını zorunlu kılmıştır. Tip yerine koyma özelliği Liskov Yerine Koyma Prensibi ile “Design by Contract” yaklaşımları çerçevesinde aşağıdaki 5 maddede belirtildiği gibi kullanılmıştır:

• 
  Çok biçimliliğin kullanıldığı durumlarda, herhangi bir metod ana sınıfa ait bir işaretçi alıp, bu işaretçi üzerinden türetilmiş sınıfların tiplerini belirlemeye yönelik bir işlem yapamaz.
  
• 
  Türetilmiş sınıflarda yeniden tanımlanan metodlar, ana sınıfta sanal tanımlanmış olmak zorundadır. Bu durumun bir sonucu olarak, olası bir karmaşıklığı önlemek amacıyla; türetilmiş sınıflar ana sınıflarına ait, sanal olmayan bir metodu aynı metod imzasını kullanarak yeniden tanımlayamazlar.
  
• 
  Türetilmiş bir sınıfa işaretçiye sahip olunmadığı sürece, ana sınıfın işaretçisi üzerinden türetilmiş sınıflara ait açık metod ve özniteliklere erişilmemelidir. Türetilmiş sınıfların metod ve özniteliklerine ulaşılırken asla ana sınıfa ait bir işaretçiyi türetilmiş sınıf işaretçisine dönüştürme yöntemi kullanılmamalıdır.
  

Örnek 3.1.1:


class AnaSınıf { public: AnaSınıf:: AnaSınıf (int iTip); int tipiDön() const; private: int _iTip; }; AnaSınıf:: AnaSınıf (int iTip) { _iTip = iTip; } int AnaSınıf:: tipiDön () const { return _iTip; } class AltSınıf1 : public AnaSınıf { public: double _dDeğer; AltSınıf 1:: AltSınıf 1(); }; AltSınıf 1:: AltSınıf 1() : AnaSınıf (100) { _dDeğer = 1.0; } class AltSınıf2 : public AnaSınıf { public: int _iDeğer; AltSınıf2::AltSınıf2(); }; AltSınıf2::AltSınıf2() : AnaSınıf (200) { _iDeğer = 2; } void yaz(const AnaSınıf & A) { int iTip; AltSınıf 1* pA1; AltSınıf 2* pA2; iTip = A.tipiDön(); switch (iTip) { case 100: pA1 = (AltSınıf1 *)&A; // İstenmeyen kullanım printf("Türetilen tip %lf\n", pA1->dDeğer); // Türetilmiş sınıfla ilgili bilgiye ihtiyaç duyuluyor break; case 200: pA2 = (AltSınıf2 *)&A; // İstenmeyen kullanım printf("The derived typed is %d\n", pA2->iDeğer); // Türetilmiş sınıfla ilgili bilgiye ihtiyaç duyuluyor break; } } void main() { AltSınıf1 A1; AltSınıf2 A2; yaz(A1); yaz(A2); }

• 
  Yazılım geliştirilirken kişiler aşağıdaki maddelere bağlı kalınarak, “Design by Contract” kuralları izlenmelidir:
  
  • 
    Sanal metodlara sahip olan ana sınıflar, metod çağırma sırasının önemli olduğu durumlarda, geçerli sıralamaları sınıf başlıklarında belirtmelidirler.
    
  • 
    Ana sınıflardaki sanal metodlar giriş gereksinimlerini ve çıkış durumlarını metod başlıklarında belirtmelidirler. Örneğin, sınıf kurucuları da dahil olmak üzere değiştirilen ve değiştirilmeyen sınıf özniteliklerinin metod başlıklarında belirtilmesi gibi.
    
  • 
    Ana sınıfa ait bir metod, türetilen sınıflardan birinde yeniden tanımlanırsa, yeniden tanımlanan metodda ana sınıfın metoduna ait giriş gereksinimleri zayıflatılmış, çıkış gereksinimleri ise güçlendirilmiş olmalıdır. Örneğin, ana sınıf metodu tarafından şart koşulan bir giriş gereksinimini, yeniden gerçeklenen metod dikkate almazken, ana metodun çıkış durumlarının tamamını halen sağlayabilmesi gibi.
    

Bu maddenin sağlanması için “Moving Map” yazılımının doğrulanma sürecinde gereksinim tabanlı testlerin yanında tasarım tabanlı testler de kullanılmaktadır. Tasarım tabanlı testlerde türetilmiş bir sınıf için ana sınıfa ait testler de koşturulmaktadır.

Aşağıdaki örnekte “Design By Contract”a aykırı bir durum gösterilmektedir.

Örnek 3.1.2:


Ana sınıf: Dikdörtgen Alt sınıf: Kare Dikdörtgen sınıfının boyutBelirle(boy,en) metodu, Kare sınıfında boyutBelirle(kenar) olarak yeniden tanımlanmıştır. Bu durumda, Kare sınıfı Dikdörtgen sınıfının ön koşulunu daha güçlü bir ön koşulla değiştirmiştir.

• 
  Ana sınıflara ait metodlar sadece gerekli olduğu bilinen durumlarda türetilen sınıflar tarafından yeniden tanımlanmalıdır.
  

3.2.Alt Sınıflar

Sınıf hiyerarşileri genelleme ilişkisiyle bağlanmış sınıflardan oluşur. NYP’de miras ve çok biçimlilik kullanımı birtakım anlamsal belirsizliklere yol açabilir. Çoklu miras kullanımında, bir sınıfın birden fazla ana sınıfa sahip olduğu durumlarda, aynı metod birkaç sınıftan miras alınabilir. Bu gibi durumlarda, metodun asıl amacı; hangi üst sınıftaki metodun mirasla alınmak istendiği belirsizleşir.
Miras ilişkilerinde, bir alt sınıfın tanımının tam olarak belirlenmemesi sınıf hiyerarşisinde yanlış konumlandırılmasına sebep olabilir.

Örnek 3.2.1:

Ana Sınıf: Dikdörtgen Alt Sınıf: Kare Yukarıdaki durum bir tasarım problemidir. Kare bir dikdörtgen çeşidi değildir. Doğru olan tasarım; ana sınıf olarak DörtKenarlıPoligon sınıfını belirlemek, Kare ve Dikdörtgen sınıflarını da bu sınıftan türetmektir.

Miras ve özellikle çoklu mirasın sık kullanılması sınıflar arasında istenmeden oluşturulmuş bağlantılara sebep olabilir ve bu durum DO-178B/ED-12B’nin veri ve kontrol bağlantıları(data and control coupling) ile ilgili gereksinimlerinin yerine getirilmesini zorlaştırır. Çoklu miras ve derin hiyerarşiler kolay hata yapılmasına sebep olabilir.

AYESAŞ “Moving Map” yazılımında kullanılan kodlama standardı sadece tekli mirasa izin vermektedir. Bu şekilde çoklu mirasın kodlama ve sertifikasyon anlamında yaratabileceği karışıklıklar önlenmiştir.
Sınıf hiyerarşilerinin karmaşık olması NYP’de karşılaşılabilecek başka bir sorundur. Çoklu miras ve derin tekli miras zincirlerinde aşırı yüklenen fonksiyonların sayısının artması bu soruna yol açabilir. AYESAŞ “Moving Map” kodlama standardında çoklu mirasın kullanıma izin verilmemesi ve miras derinliğinin sınırlandırılmasıyla bu sorun çözülmüştür.
Ana sınıfta yeralan bir metod alt sınıflar tarafından yeniden tanımlanabilir. Bu konuda dikkat edilmesi gereken nokta, bazı NYP dillerinde fonksiyon isimlerinin aşırı yüklenmesi ile ilgili kısıtlamalar olmadığı için, metodların farkında olmadan yeniden tanımlanabilmesidir.
Yeniden tanımlanan bir metodda bir değişkene bağlı olarak yapılan bir hesaplama, ana sınıftaki metodla anlamsal olarak aynı değilse birtakım beklenilmeyen sonuçlar ortaya çıkabilir.
Örnek 3.2.2 :

class AnaSınıf { public: virtual int metodA(); double metodB(); }; int AnaSınıf::metodA() { return 2; } double AnaSınıf::metodB() { return 2.0; } class AltSınıf1 : public AnaSınıf { public: int metodA(); // Yeniden tanımlama amaçlanmamış. void AltSınıf1_metod(); }; int AltSınıf1::metodA() { return 5; } void AltSınıf1::AltSınıf1_metod() {} void main() { AltSınıf1 A1; AnaSınıf * pMB = &A1; A1.metodA(); // AltSınıf1::metodA, çağırılır. pMB->metodA(); // Çok biçimlilik beklenmediği halde, // AltSınıf1::metodA metodu çağırılır. }

3.3.Aşırı Yükleme

Aşırı yükleme, kısaca aynı isimdeki metodların değişik özellikte parametreler alarak işlem görmesi olarak tanımlanabilir. Aşırı yükleme kullanımının potansiyel tehlikesi, kodu kompleks ve test edilmesi zor bir hale getirebilmesidir.
Aşırı yükleme kullanımı, yazılımda beklenmeyen davranışların ortaya çıkmasına sebep olabilir. Örneğin, birbirine dolaylı olarak çevrilebilir tiplere sahip parametreleri olan metodlar aşırı yüklenirse, asıl çağırılmak istenen metod yerine derleyicinin çağırılmasına karar verdiği metod çağırılabilir.
Örnek 3.3.1:

class AnaSınıf { private: long _lDeger1; public: AnaSınıf(); virtual void metodA(long lDeger); }; AnaSınıf:: AnaSınıf () { } void AnaSınıf::metodA(long lDeger) { _ lDeger1 = lDeger; } class AltSınıf : public AnaSınıf { private: double _dDeger1; public: AltSınıf(); void metodA(double dDeger); }; AltSınıf:: AltSınıf() { } void AltSınıf::metodA(double dDeger) { _dDeger1 = dDeger; } void main() { AltSınıf A1; double d = 10.0; long l = 100; A1.metodA(d); // AltSınıf::metodA(double)çağırılır A1.methodA(l); // l double’a çevrilir ve // AltSınıf::metodA(double) çağırılır A1. AnaSınıf::metodA(l); // AnaSınıf::metodA(long) çağırılır }

Örnekte aşırı yüklemenin yol açabileceği bir sorun gösterilmektedir. metodA’nın ilk çağırılışı beklendiği üzere türetilmiş sınıfa ait olan methodA’yı çağırmaktadır. Fakat, metodA’nın ikinci çağırılışında ana sınıfa ait olan metodA’nın çağırılması beklenirken, derleyici “long” tipini “double”’a değiştirir ve beklenenden farklı olarak türetilmiş sınıfa ait olan methodA çağırılmış olur. metodA’nın üçüncü çağırılışı da beklendiği gibi temel sınıfa ait metodA’nın çağırılmasına yol açacaktır.
Aşırı yükleme kullanımının yaratabileceği sorunlara engel olabilmek için, AYESAŞ “Moving Map” yazılımı kodlama standardında sanal metotların aşırı yüklemesine izin verilmemektedir. Diğer bütün metodların aşırı yüklenmesi, tasarımın gözden geçirilmesi sırasında gerekli açıklama yapıldığı sürece kabul edilmektedir. Sanal metodların aşırı yüklenmesine izin verilmemesinin sebebi ise bu durumun yaratabileceği karışıklığı önlemektir. Bu gibi durumlarda, bilinçli olarak argüman sayısı veya argümanlarının tipleri farklı olan bir metod tanımlanıp tanımlanmadığı ya da bir ana sınıf metodunun üzerine yazmayı amaçlayıp, yanlışlıkla metodun argüman sayısı veya argüman tiplerini değiştirerek aşırı yükleme yapılıp yapılmadığı tam olarak anlaşılamaz.

3.4.Gereksinimlerde Belirtilen İşlevsellik Dışında, Gerekmeyen Kod

Nesne yönelimli programlamada karşılaşılabilecek diğer bir sorun da; gereksinimlerde belirtilen işlevsellik dışında, gerekmeyen kod parçalarının tespit edilmesinin zorluğudur. Gerekmeyen kod parçaları; bir uygulamada bir sınıfa ait metodların çağırılmaması, bir sınıfa ait tüm metotların o sınıftan türetilen sınıflarda yeniden tanımlanması veya bir sınıfın özniteliklerine belirli bir uygulamada ulaşılmaması durumlarında ortaya çıkabilir. DO-178B standardına göre, gerekmeyen kod parçalarının aviyonik yazılımlarında bulunmaması gerekir.
Gereksinimlerde belirtilen işlevsellik dışında, gerekmeyen kod parçalarının bulunması için AYESAŞ bünyesinde Yapısal Kaplama Analizi(YKA) yapılmaktadır. YKA, gereksinim tabanlı test prosedürlerinin, var olan kodun yapısının ne kadarını çalıştırdığının bir ölçütüdür. Bu analiz ile, istemsiz olarak yazılımın içerisinde yeralmış kod parçacıklarını belirlemek mümkün hale gelir. Aynı zamanda, bu analiz hazırlanmış olan “Gereksinim Tabanlı Test” prosedürlerinin yetkinliği hakkında da bilgi sahibi olunmasını sağlar.

3.5.Bellek Yönetimi ve İlklendirme İle İlgili Sorunlar

DO-178B standardına göre (Bölüm 11.10), yazılım tasarlanırken belleğin sınırlamalara göre yönetimi için bir strateji geliştirilmelidir. Nesne yönelimli programlarda, sınıf hiyerarşileri (özellikle derin hiyerarşiler) ilklendirme sorunlarına yol açabilmektedir. Buradaki temel sorun, türetilmiş bir metodun daha üst seviyedeki bir kurucu tarafından, türetilmiş metoda ait olan öznitelikleri ilklendirilmeden önce çağırılabilmesidir.
AYESAŞ “Moving Map” yazılımında Devingen Bellek Ayırma(new ve malloc) sadece ilklendirme(initialization) aşamasında yapılır. Ayrılmış olan bellek “free” veya “delete” kullanılarak asla geri verilemez. İlklendirme sırasında nesneler için bir arabellek ayrılır ve ara bellekten nesnelerin yaratılması ve silinmesini simüle eden bellek yönetimi kodu yazılır. Bellek ayırmanın ilklendirme aşamasından sonra yapılmamasını garanti altına almak için iki yöntem izlenir. Birincisi, ilklendirmeden sonra bellek ayrılmadığını kodu inceleyerek ispatlamaktır. Diğer yöntem ise, tasarıma ilklendirmeden sonra bellek ayrılmaya çalışıldığında yazılımın çalışmamasını sağlayan bir bayrak koymaktır.
Örnek 3.5.1:

// Header file for MemNew class void* operator new (size_t size); void* operator new[] (size_t size); class MemNew { public: static bool bBlockGlobalMemAlloc; static void* DaveNew::getMemory(size_t size); };

// Source file for MemNew class void* operator new (size_t size){ return MemNew::getMemory(size); } void* operator new[] (size_t size){ return MemNew::getMemory(size); } void* MemNew::getMemory(size_t size){ void* mem = NULL; if (!MemNew::bBlockGlobalMemAlloc){ mem = _nh_malloc( size, 1 ); } return mem; }

Yukarıdaki kod parçası, new operatörünün aşırı yüklenmesini göstermektedir. getMemory() metodu, bellek ayırma yapmadan önce bBlockGlobalMemAlloc bayrağının değerini kontrol ediyor. Eğer bayrak değeri uygun değilse(ilklendirme tamamlanmışsa), bellek ayırma işlemi başarısız olur ve metod NULL döner.

4.Sonuç

NYP’nin, kompleks sistemlerin yeniden kullanılabilir bileşenler sayesinde daha verimli bir şekilde geliştirilebilmesi ve tasarım kararlarının saklanması gibi özellikleri sayesinde güvenlik-kritik sistemlerde kullanımı giderek artmaktadır. Havacılık sektörü tarafından ortaya konulan ve kullanılan DO-178B/ED-12B standardı, kısa sürede güvenlik-kritik yazılım ihtiyacı olan otomotiv, medikal gibi diğer sektörler tarafından da kullanılmaya başlanmıştır. Yakın zamanda yayınlanacak olan DO-178C standardında NYP’nin de ele alınacak olmasının, bu kullanımı daha da arttıracağı düşünülmektedir. Bu bağlamda güvenlik ve sertifikasyon ile ilgili olası problemleri belirlemek, NYP’nin aviyonik yazılımlarda güvenli bir şekilde uygulanması açısından büyük önem taşımaktadır. Bu bildiride, AYESAŞ’ın “Moving Map” Yazılım projesinin gerçeklenme aşamasında, NYP’nin güvenlik-kritik sistemlerde kullanımı ile ilgili karşılaşılan problemler ve uygulanan çözümler sunulmuştur.

5.Kaynakça

[1]. Booch, Grady. - Object-Oriented Analysis and Design. Addison-Wesley, 2nd edition, 1994.

[2]. “Glossary of Software Engineering Terminology.” ANSI/IEEE Standard, 1983.

[3]. Liskov, Barbara H., Jeanette M. Wing. “A Behavioral Notion of Subtyping,” ACM Transactions on Programming Languages and Systems, Nov. 1994, vol. 16, no. 6, pp. 1811-1841

[4]. RTCA DO-178B, “Software Considerations in Airborne Systems and Equipment Certification”, 1992

[5]. EUROCAE/ED-12B, “Software Considerations in Airborne Systems and Equipment Certification”, 1992

[6]. Meyer, Bertrand. Object-Oriented Software Construction. Prentice Hall, 2nd edition, 1997

[7]. Object Oriented Technology in Aviation Program. Handbook for Object-Oriented Technology in Aviation (OOTiA), January 2004