Emniyet Kritik Sistemlerde Model Tabanlı Doğrulama ve Gereksinim

Emniyet Kritik Sistemlerde Model Tabanlı Doğrulama ve Gereksinim

5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
Emniyet Kritik Sistemlerde Model Tabanlı Doğrulama ve
Gereksinim Gözden Geçirme
Alper KENDİ
Yazılım Müdürlüğü, STM A.Ş., Ankara
e-posta: [email protected]
santrallere kadar farklı yapı ve davranışlardaki sistemlerin
modellenebilmesi için elverişlidir. UML/SysML gösterimi
grafiksel ve kolay anlaşılır dört temel tipten oluşmaktadır [3].
Özetçe
Bu makalenin amacı, güvenlik kritik yazılım geliştirme
çevriminde karşılaşılan gereksinim kaynaklı hataların erken
tespit edilmesine yardımcı bir yöntem anlatmaktır. Bu yöntem
ile gereksinim tabanlı modelleme ve model üzerinden
doğrulama yaklaşımı kullanılarak, yüksek verimli gereksinim
gözden geçirilmesine ve beraberinde az hatalı, tutarlı ve test
edilebilir gereksinim oluşturulmasına imkân verilmektedir.
2.1. Yapısal Gösterim
Yapısal gösterim sistem elemanlarının niteliklerinin, sağlanan
servislerin ifade edildiği, yazılım sisteminde sınıf, nesne gibi
yapılara karşılık gelen ve bu gibi yapıların modellenmesi için
araçlar içeren gösterim şeklidir. Yapısal gösterim yazılım
geliştirme süreci bakımından daha çok yazılım tasarım
aşamasında önemini gösteren ve daha sık kullanılan bir yapı
olsa da gereksinimlerden oluşturduğumuz modellerin tasarım
içermemesi, başka bir ifade ile tasarımı tarif etmesinin
sakıncalarından ötürü gereksinim doğrulama bakımından
önem arz etmemektedir. Şekil 1 dost düşman tanıma
sisteminin basit bir yapısal gösterimidir.
1. Giriş
1980’li yıllardan başlayarak büyüyerek yayılan ve yaşamın her
noktasında kendilerini gösteren yazılımlara, konusu insan
yaşamı olan uygulamalarda ihtiyaç duyulmaya başlandı. İnsan
yaşamının emanet edildiği bu tür yazılımların geliştirilmesine
yazılımın üstlendiği sorumluluktan ötürü elverişlilik,
güvenilirlik ve benzeri gibi ölçütler, uyulması zorunlu
standartlar ile denetimler getirildi. Günümüzde halen
mühendisler, insanoğlunun doğası gereği hata yapma
alışkanlığı karşısında, insan üretimi fakat hata yapmayan
yazılım geliştirilmesi zorunluluğu ile kıyasıya mücadele
vermektedir. Bu mücadele güvenlik kritik yazılım geliştirme
çevriminde, hata bulmaya ve önlemeye yönelik yeni
yöntemlerin ortaya çıkartılması ve uygulanması ile insan-hata
denkleminde mühendislerce kazanılması zaruri bir mücadele
halini almıştır.
Model güdümlü doğrulama, model güdümlü geliştirme
yönteminin gereksinimlerin gözden geçirilmesine yönelik bir
uyarlamasıdır. Binlerce satırlık gereksinim kümeleri içerisinde
kaybolmadan, anlaşılır ve çalıştırılabilir modeller üzerinden
gözden geçirmelerin gerçekleştirilerek, projenin ilerleyen
aşamalarında ortaya çıkması muhtemel hataların henüz sisteme
girmeden tespit edilmesine olanak sağlar. Bu bildiride
öncellikle model güdümlü geliştirmenin genel bir tanımı
verilerek, model güdümlü doğrulamanın DO-178B gibi
standartlar kılavuzluğunda geliştirilen güvenlik kritik
yazılımlarda hata bulma üzerine etkileri ve sağladığı faydalar
yazarın deneyimlerine dayandırılarak anlatılacaktır.
Şekil 1 Yapısal Gösterim Örneği
2. Model Güdümlü Yaklaşım
2.2. Fonksiyonel Gösterim
Birleşik Modelleme Dili
(UML) günümüzde karmaşık
sistemlerin yapı ve ilişkilerinin başarılı bir şekilde ifade
edilebildiği, sistemin uygulama sahası, geliştirme süreci,
kullanılan teknoloji gibi unsurlardan bağımsız olarak
modellenebildiği ve Object Management Group (OMG) isimli
kuruluş tarafından standart haline getirilen bir dildir. SysML
varyasyonu ile birlikte UML, yazılım sistemlerinden nükleer
Fonksiyonel gösterim, sistem fonksiyonları ve kabiliyetleri
üzerinde duran, UML/SysML gösteriminde “use-case”
diyagramlarının sıklıkla kullanıldığı, sistemin tam olarak
“ne” yaptığı sorusunun yanıtını verirken, “nasıl” sorusuna
cevap vermekten kaçınılması gereken gösterim biçimidir.
Sistem fonksiyonlarının modellenmesi oldukça kolay gibi
görünse de sistem tasarımında üzerinde en çok durulması ve
258
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
ekip olarak fikir alışverişinde bulunularak ilerlenmesi gereken
bir süreçtir. Aksi takdirde sistem bir sonraki aşamada hiç
kullanılmayacak yüzlerce kullanım senaryosu (use-case)
modeli içerisinde kaybolacaktır. Orta büyüklükte bir aviyonik
projede önerilen, use-case modeli sayısının 6-10 arasında
tutulmasıdır [2]. Anlaşılabilirlik açısından faydalar sunan
fonksiyonel modelleme, doğrulama ekiplerinin sistem
bütününü daha rahat anlamasına ve doğrulama adımlarının
tatbikinin sağlıklı yapılmasına imkân vermektedir. Şekil 2 de
gösterilen elektronik harp sistemi hedefi etkisiz hale getirmek
için dost düşman tanıma sisteminden faydalanmaktadır.
2.4. Etkileşimsel Gösterim
Etkileşimsel gösterimler, tanımlı bir senaryo üzerinden mesaj
tabanlı davranışların ifade edilmesi için uygundur.
Etkileşimsel gösterimi yapılmış bir sistemin parçaları
arasındaki iletişimi ve senaryo akışı görülebilir. Şekil 4’te
görüleceği üzere etkileşimsel gösterimde sıklıkla kullanılan
sıralama (sequence) diyagramları, sundukları yaşam çizgisi ile
zamana dayalı mesajların gösteriminde de başarılıdır. EHMS
sistemi, pilota tehdit raporlandıktan sonra 2 saniye içerisinde
komut almaya hazır duruma gelebilmelidir.
Şekil 2 Fonksiyonel Gösterim Örneği
Şekil 4 Etkileşimsel Gösterim Örneği
2.3. Davranışsal Gösterim
Davranışsal gösterim UML/SysML dilinde çoğunlukla
durum (state machine) ve aktivite (activity) diyagram tipleri
ile gösterimi yapılan sistem durumlarının, bir durumdan
başka bir duruma geçilmesi için gerekli şartların ve tetik
mekanizmalarının ifade edildiği, model güdümlü doğrulama
yaklaşımında önem arz eden bir gösterim şeklidir. Davranışsal
gösterimi yapılan sistemlerde, gereksinim aşamasında sıklıkla
karşılaşılan ve gözden geçiriciler için yakalanması zor olan
kontrol akışı aykırılıkları, davranışsal gösterimi yapılan sistem
modellerinde kolaylıkla görülebilmektedir. (bkz.Şekil 3)
3. Model Tabanlı Doğrulama
Gözden geçirme, yazılım endüstrisinde yazılım geliştirme
yaşam döngüsü ürünlerindeki hataları ortaya çıkartmaya
yönelik, maliyeti düşük doğrulama tekniklerinden biri halini
almıştır. Gözden geçirmelerin birincil amacı olan hata
yakalama, sistem ile ifade edilen yapıdaki olağan dışı tüm
sapmaları kapsamaktadır. Konusunda uzman gözden
geçiriciler ön tanımlı bir süreç çerçevesinde gereksinim,
kaynak kod vb. çıktıların hatalarını bulmaya yönelik
çalışmalar yapmaktadır. Bu çalışmalarda kullanılan Active
Design Review, Two-Person Review, N-Fold Review vb.
gözden geçirme teknikleri gözden geçirmelerin kalitesini
yükseltmeye yönelik adımlar, yöntemler içermektedir [5].
Günümüz şartlarında gözden geçirilecek ürünlerin
büyüklüklerinin getirmiş olduğu karmaşıklığın çözümü için
mevcut metotlar, gözden geçirilecek ürünlerin mantıksal
bölümlere ayrılıp, yönetilmesi üzerine farklı yöntemler sunar.
Tüm bu tekniklerin temelinde yatan ve gözden geçirmenin
anlaşılabilirliğini artırmaya yönelik adımlar Model Güdümlü
yaklaşım ile bir üst noktaya taşınmaktadır. Model üzerinden
doğrulama yapmanın anlaşılabilirliği, pek çok gereksinimin
tek bir model elemanı ile ifade edilebilmesinin ve mevcut
modellerin çalıştırılabilmesinin gözden geçiriciye sağladığı
kolaylık, yakalanan kritik olarak adlandırılabilecek hata
sayısını artırmakta, bu durum projenin ilerleyen safhalarında
ortaya çıkması olası hataların önüne geçilerek maliyetleri
azaltmaktadır.
Şekil 3 Davranışsal Gösterim Örneği
259
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
Şekil 5 Sistem Açılış Durumları
Gereksinimler ile örtüşen fakat tasarım tarif etmeyen
model elemanlarının oluşturulması, oldukça dikkat ve tecrübe
isteyen bir uğraş olsa bile sistem tasarımına girdi teşkil etmek
maksadı ile oluşturulan bu modellerin, doğrulama amaçlı
kullanımı gereksinim kaynaklı özellikle kontrol akışına
(control flow) yönelik hataların bulunmasında etkin bir
yöntem olarak karşımıza çıkmaktadır. Test yoğun faaliyetler
olan güvenlik kritik uygulama geliştirme süreçlerinde testler,
geliştirme eforunun %35 gibi bir kısmını oluşturabilir [4].
Süreç dâhilindeki test faaliyetlerinde, DO-178B gibi
kılavuzlarda karşımıza çıkan yapısal kapsam analizi (SCA)
gibi metotlar kullanılarak hata yakalama oranları
yükseltilebilmektedir. Sisteme girmiş hataların testler
esnasında bulunacağı düşünülerek ilerlemek ise proje
maliyetleri açısından dezavantajlıdır. Zira hatanın sisteme
girmesi ile hatanın sistemde tespit edildiği safha ters orantılı
olarak maliyetleri artırmaktadır. Sürecin başında (gereksinim
aşaması) sisteme giren hatalar ve sürecin sonunda (kullanım
aşaması) ortaya çıkarılan hatalar firmalara yüksek maliyetli
zararlar veren hatalardır. Testler esnasında ortaya çıkan
gereksinim kaynaklı bir hata, yazılım kaynak kodunun
değişmesine, değişen yazılım kaynak kodu yazılım
tasarımının değişmesine, tasarımın değişmesi, yazılım
gereksinimlerinin değişmesine kadar gidebilecek bir döngüyü
tetikleyerek, zaman ve para kayıplarına yol açabilmektedir.
Hata yapması durumunda can kaybına yol açması muhtemel
(DO-178B kılavuzundaki muadili ile seviye A) 10K satırlık
güvenlik kritik bir yazılımda, kullanım aşamasında bulunan
hatanın üreticiye maliyeti 500K-1M $ arasında değişmektedir.
Bu noktada hataların tespit edilmesi kadar hataların geliştirme
sürecinin hangi safhasında tespit edilebildiği de önem
kazanmaktadır [1-4].
Yukarıdaki şekilde (bkz. Şekil 5) modeli verilen örnek, bir
hava aracının seyrüsefer sisteminin cihaz içi testlerini
gerçekleştirecek yazılımın, metin tabanlı gereksinimlerinden
oluşturulmuştur. Cihaz içi testler aviyonik cihazların
açılışında, kullanım esnasında otomatik olarak veya
pilot/bakım elemanı tarafından başlatılmak suretiyle çalışan,
aviyonik sistemdeki ön tanımlı durumları kontrol eden, kısaca
aviyonik donanım ve yazılımın düzgün çalıştığını
doğrulamaya yönelik testlerdir. Şekil 5’te gösterilen PBIT
(power up built-in test) durumu sistemin donanım sınama
testlerinin çalıştığı açılış cihaz içi test durumudur.
Örneğimizdeki 29 adet ön tanımlı donanım sınama testi,
sisteme güç verilmesinin ardından, PBIT durumunda otomatik
olarak çalıştırılıp, ilgili testlerden çıkan sonuçlara göre
sistemin açılış şekli tespit edilmektedir. Sistemin test
sonuçlarına göre 3 farklı açılış durumu mevcuttur. Birinci
durum tüm test sonuçlarının “Geçti” olduğu model üzerinde
“isAllSuccess()” metoduyla kontrol edilen ve sistemde ön
tanımlı hiçbir hatanın bulunmadığı normal (Normal Mode)
durumudur. İkinci durum ön tanımlı hatalardan bir kısmının
olduğu, yine de sistemin açılışının kısıtlanmış kabiliyetler ile
gerçekleştirilebileceği indirgenmiş durum (Degrade Mode) ve
son olarak sistemde fonksiyonel olarak sağlıklı bir açılışa
imkân vermeyecek düzeyde kritik hataların bulunduğu hata
(Fail Mode) durumudur. Sisteme güç verilmesinin ardından
29 adet ön tanımlı donanım sınama testi sırasıyla
çalıştırılacak, tüm test sonuçlarının geçmesi durumunda
sistem normal (Normal Mode) durumuna, indirgenmiş
işlevsellik ile açılış yapılması gerekiyorsa indirgenmiş
(Degrade Mode) durumuna, eğer sistemde kritik hatalar
bulunduysa sistem hata (Fail Mode) durumuna geçecektir
(bkz. Şekil 5).
Metin tabanlı gereksinimlerin gözden geçirilmesi
günümüz sistemleri düşünüldüğünde bir insanın bütünüyle
hâkim olamayacağı karmaşıklıkta olabilmektedir. DO-178B
ve benzeri standartların gözden geçirme kalitesini artırmaya
yönelik bağımsız gözden geçirici zorunluluğu, gereksinimleri
yazanlar ile gözden geçirenlerin farklı kişiler olmasını
gerektirmektedir. Bu durum, gereksinimi yazan saha
uzmanlarının diğer insanların da ilgili konuda uzman
olduğunu varsayarak gereksinim oluşturmaları gerçeği ile
birleştiğinde, gereksinimin gözden geçirici tarafından
anlaşılıp, hata bulmaya yönelik kaliteli bir gözden geçirme
faaliyetinin icra edilmesi zorlaşmaktadır.
Metin tabanlı gereksinimler incelendiğinde kontrol akışında
bir problem görülmemektedir fakat kontrol akışımızda metin
tabanlı gözden geçirilme ile tespit edilmesi zor 2 adet önemli
hata bulunmaktadır. “Sistem açılışında, tüm testlerin geçmesi
durumunda sistem normal (Normal Mode) durumunda
başlatılacaktır.” şeklinde bir gereksinim maddesinde gözden
geçirici için dikkat edilen noktalar çoğunlukla giriş koşulları
olmaktadır. Çıkış koşulları ve çıkış koşullarına bağlı diğer
durum giriş şartları yani resmin tamamı metin tabanlı bir
gözden geçirmede kolaylıkla hakim olunabilen bir durum
değildir. Tüm testler geçtiği takdirde sistem normal durumuna
geçecek; eğer testler aracılığı ile bir hata tespit edilirse
hatanın cinsine göre sistem indirgenmiş veya hatalı mod
260
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
durumlardan birisine geçecektir. 2 adet önemli eksiklikten biri
sistemin indirgenmiş ve hata durumlarına geçmesinden sonra
kendini göstermektedir. Gereksinimler içerisinde sistemin
indirgenmiş ve hata durumlarından hangi koşulda veya
koşullarda çıkacağı belirtilmemiştir. Hata veya indirgenmiş
durumuna geçen sistemin yeniden başlatılması, bir süre sonra
kendiliğinden kapanması veya sistemin ikinci bir tetiklenmeye
kadar mevcut durumunu koruması şeklinde çıkış koşullarının
gereksinimlere eklenmesi gerekmektedir. Aksi takdirde
yukarıda bahsi geçen gereksinim setine göre geliştirilmiş
aviyonik yazılım Şekil-6’da görüldüğü üzere 1 hata veya
indirgenmiş durumlarına girdiğinde, sistem gücü kapatılıp
açılıncaya kadar bu durumda bekleyecektir.
Şekil 7 Zaman Aşımı Hatası
4. Sonuçlar
DO-178B kılavuzluğunda ilerlenen projelerde sistem
gereksinimlerinden oluşturulan yazılım yüksek seviye
gereksinimleri (High Level Requirements) yazılım sisteminin
tam olarak ne yapacağını tüm detayları ile ifade etmektedir.
Bu detayda yazılan gereksinim setlerinin metin tabanlı olarak
gözden geçirilmeleri, hataların gözden kaçırılmasına zemin
hazırlamaktadır. Yukarıda bir bölümünden örnek verilen
“Cihaz İçi Test” bileşeninin gereksinimleri içerisinde,
bileşenin hata durumundan hangi olay/koşul ile çıkacağı ve
zaman aşımı oluşması halinde bileşenin nasıl davranacağı gibi
gereksinimler ifade edilmemiştir. Model tabanlı doğrulama,
ön gözden geçirme çalışmalarımızda metin tabanlı
gereksinimlerin resmi gözden geçirilmeleri sırasında gözden
kaçması muhtemel bu iki eksikliğin ortaya çıkartılmasında
görev almıştır. Yirmi dört adet metin tabanlı gereksinimin,
model üzerinden yapılan ön gözden geçirmeleri sırasında
ortaya çıkartılan iki adet eksiklik, Şekil 5’te görülen hata
durumunun (Fail Mode) çıkış şartı olarak eklenmiş yeniden
başlat (evRestart) tetiği ve açılış cihaz içi test (PBIT)
durumuna eklenmiş “tm(18000)” zaman aşımı mekanizması
ile çözümlenmiştir. Model tabanlı doğrulama yöntemi,
günümüz teknolojisinde Şekil 6-7 de görülen çalıştırılabilir
modeller sayesinde henüz tasarım ve kaynak kodun
oluşturulmadığı proje safhalarında, akış kontrollerindeki
aksayış ve eksikliklerin tespit edilmesine imkân vermektedir.
Bu sayede projenin ilerleyen aşamalarında ortaya çıkabilecek
ve firmaya iş ve zaman kaybına yol açabilecek hataların henüz
gereksinim gözden geçirmeleri esnasında çözümlenmesine
olanak sağlanmıştır.
Şekil 6 Kontrol Akışı Hatası
Gereksinimlerde geçtiği şekli ile sistem 29 adet donanım
sınama testinin çalıştırılıp, testlerin sonuçlarına göre ön
tanımlı durumlardan birine geçmektedir. Metin tabanlı
gereksinimlerin gözden geçirilmesi esnasında fark edilmeyen
diğer bir akış sıralı halde çalışan 29 adet testten bir tanesinden
yanıt alınamaması koşulunda sistemin düşeceği kararsız
durumdur.
Aviyonik
donanımlar,
özellikle
askeri
uygulamalarda oldukça zorlu çevre koşullarında çalışmak
zorundadır. Arızalanmış bir sensörden veri okumaya çalışan
29 adet ön tanımlı testten bir tanesi hiçbir zaman geçti/kaldı
şeklinde bir neticeyle sırasını devretmeyebilir. Sistemde
tanımlı bir sonraki testin çalıştırılması mümkün olmayabilir
veya
sistem
donanım
sınama
testlerinin
dahi
çalıştırılamayacağı bir arızaya sahip olabilir. Bu durumda
Şekil-7’de görüldüğü üzere 2 sistem, testlerin koşturulduğu
PBIT durumunda çıkmaza girecektir. İlgili gereksinimler
içerisine eklenecek bir madde ile 29 adet ön tanımlı testin
tamamlanması için bir zaman aşımı tanımlanıp, bu süre
içerisinde testlerin tamamlanamaması durumunda, sistemde
ciddi bir hatanın olduğu kabul edilerek sistem hata (Fail
Mode) durumuna geçirilmelidir.
5. Teşekkür
Çalışmalarım sırasında desteklerini esirgemeyen ve değerli
görüşleri ile deneyimlerin bir bildiri haline gelmesine yön
veren Sayın Serkan Çak ve mesai arkadaşım M.Umut
Pişken’e teşekkür ederim.
1
Şekil-6 ve Şekil-7 oluşturulan modellerin yardımcı araçlar
kullanılarak çalıştırılması ile elde edilmiş ekran görüntüleridir. Pembe
çerçeveli alanlar o an aktif olan durumları(state), sarı çerçeve, aktif
olan duruma geçilmeden bir önceki aktif durumu belirtmektedir.
Şekildeki “FailMode” durumundan çıkış koşulu olan “evRestart”
olayı(event) gereksinim setine ve modele hatanın tespitinin ardından
eklenmiştir.
2
Şekil 7 te görülen “tm(18000)” zaman aşımı, hatanın
gereksinimdeki
eksikliğinin
tespit
edilmesinin
ardından
gereksinimlere ve modele eklenmiştir.
6. Kaynakça
[1] ``RTCA/DO-178B Software Considerations In Airborne
Systems And Equipment Certification”, RTCA, Inc.
1992.
[2] Bruce Powel Douglass, “Real-Time UML Workshop for
Embedded Systems”, Elsevier, Oxford, 2007
[3] OMG Systems Modeling Language (OMG SysML),
Document Number formal/2008-11-01, 2008
261
5. ULUSAL YAZILIM MÜHENDİSLİĞİ SEMPOZYUMU - UYMS'11
[4] Hilderman, Vance, “DO-178B Costs Versus Benefits”,
www.highrely.com/ whitepapers.php, 2006
[5] Yuk Kuen Wog, “Modern software review: Techniques
and Technologies”, IRM Press, 2006
262