Dağıtık Benzetim Sistemleri İçin Entegrasyon ve Test Yaklaşımları

Transkript

1 Dağıtık Benzetim Sistemleri İçin Entegrasyon ve Test Yaklaşımları Integration and Test Approaches for Distributed Simulation Systems Savaş Öztürk, Esma Kılıç, Özden Erkan ve Oğuz Dikenelli TÜBİTAK MAM BTE, PK 21, Gebze, KOCAELİ savas.ozturk, esma.kilic, ozden.erkan, Özet Benzetim sistemleri maliyetli, zaman alan ve riskli görevlerin eğitiminde sıklıkla kullanılmaktadır. Benzetimlerin gerçek hayat koşullarına uygunluğunu sağlamak amacıyla dağıtık benzetim mimarileri geliştirilmiş, farklı yerlerde ve farklı kişi veya ekipler tarafından geliştirilmiş benzetimlerin birlikte çalışabilirliği hedeflenmiştir. Benzetimin işlevsel karmaşıklığına ek olarak dağıtık yapının da getirdiği karmaşıklık bu tip sistemlerin test edilebilirliğini zorlaştırmakta ve test sürecini, dağıtık benzetim projelerinin en kritik süreci haline getirmektedir. Bu çalışmada HLA tabanlı dağıtık bir benzetim sisteminin entegrasyonu ve testlerine getirilen çözüm sunulmuş, çözüme giden yolda yapılan çalışmalar anlatılmıştır. Abstract Simulation systems are frequently used at training of missions those cost much, require much time and carry risk on human life and goods. Distributed simulation system architectures are developed in order to improve the real time suitability and it is aimed to interoperate the simulations together, which are developed by different developers or teams at different places. Beside the functional complexity, the distributed architecture brings some more complexity which makes testing such systems harder, and causes the testing process to be the most crucial process in the distributed simulation projects. In this study, the solution to the integration and the testing process of a distributed HLA based simulation system is presented and the lessons learned during the solution phase are provided. 1. Giriş Yazılım teknolojilerinin gelişimi çok değişik alanlarda büyük çaplı gelişmelere yol açmıştır. Görsel modelleme tekniklerinin, işlemci performanslarının, ağ performanslarının ve çeşitliliğinin artması da benzetim sistemlerini olumlu yönde geliştirmiştir. Doksanlı yılların sonuna doğru bir IEEE standardı olarak da akredite edilen High Level Architecture (HLA), benzetimlerin birlikte çalışabilirliğine ve tekrar kullanılabilirliğine olanak sağlayan, eğitim, mühendislik, analiz ve hatta eğlence gibi değişik alanlarda uygulama alanı bulmuş bir yazılım mimarisidir [1]. Tüm dünyada olduğu gibi ülkemizde de HLA üzerinde çalışmalar yapılmakta, araştırma ve test ortamları oluşturulmaktadır [2]. Bir dağıtık benzetim sistemi, dağıtıklığı, gerçek zamanlı oluşu, simüle ve gerçek bileşenleri birlikte barındırması, farklı teknolojilere ve yöntemlere açık olması gibi özellikleri sebebiyle geliştirilmesi, entegrasyonu ve test edilmesi karmaşık bir sistemdir ve özgün bir test yaklaşımı gerektirir. Bu tür sistemlerin test sürecinin planlanması ve yönetimi, yaşam döngüsü yaklaşımına uygun olarak disiplinli bir biçimde yapılmalı, gelişigüzel yöntemlerden kaçınılmalıdır [3]. Bu çalışmada, TÜBİTAK Marmara Araştırma Merkezi Bilişim Teknolojileri Enstitüsü nde geliştirilen HLA tabanlı bir dağıtık benzetim projesi kapsamında tanımlanan test süreci tanıtılmaktadır. Bu bağlamda, ikinci bölümde HLA mimarisi tabanlı bir sistemin geliştirilme sürecine değinilmiştir. Üçüncü bölümde geleneksel test seviyeleri ile o seviyeleri karşılık gelen önerilen test tipleri anlatılmıştır. Dördüncü bölümde önerilen test tipleri için test tasarımlarının ve test durumlarının belirlenmesi için izlenen prosedür gösterilmiştir. Beşinci bölümde ise projedeki test süreci deneyimlerine dayalı olarak dikkat edilmesi gereken noktalar listelenmiştir. 2. HLA ile Dağıtık Benzetim Geliştirme Distributed Interactive Simulation (DIS) ve Aggregated Level Simulation Protocol (ALSP) gibi daha önceki dağıtık benzetim altyapı teknolojilerinden farklı olarak HLA tabanlı bir sistemde, her mesaj ihtiyacı olan veya olmayan bütün benzetimlere gönderilmek yerine, publish / subscribe (yayınla / abone ol) yöntemiyle sadece abone olanlara gönderilir. Aynı şekilde, sadece yayınlamakta sorumlu olduğu mesajları yayınlayabilir. Bu mekanizma ağın ve benzetim sisteminin yükünü azaltarak performansı artırır. Bir HLA uygulamasında her bir bağımsız benzetim uygulamasına federe adı verilir. Federe kümesinden oluşan sisteme ise federasyon adı verilir. Federeler

2 birbirleri ile direk iletişim kurmazlar, Runtime Infrastructure () adı verilen ve HLA mimarisinde federasyonun omurgasını oluşturan yazılım üzerinden haberleşirler. Federeler arası etkileşim ise iki temel şekilde olabilir: a) Etkileşim (Interaction) mesajı b) Nesne güncellemesi (Object update) Hangi federenin hangi nesne ya da etkileşimi yayınlayacağı ya da abone olacağı Federate Object Model (FOM) adı verilen model dosyasında belirtilir. Federe ve federasyonların geliştirilmesi için IEEE tarafından Federation Development and Execution Process (FEDEP) süreci tanımlanmıştır [4]. Bu süreç, isterlerin belirlenmesinden entegrasyon ve teste kadar genel yazılım yaşam döngüsü süreci ile benzer olup sürekli güncellenmektedir. FEDEP sürecindeki en önemli basamaklardan birisi olan kavramsal model analizinin gerçekleştirilmesinde Base Object Model (BOM) kullanılabilir [5]. BOM ile tanımlanan kavramsal modelden federasyon mimarisine geçmek gerekmektedir ve bu geçiş yöntemi Timar ve arkadaşları tarafından detaylandırılmıştır [6]. HLA tabanlı bir benzetim sisteminin gürbüz bir şekilde yüksek performans ile çalışmasında federe davranış ve karakteristikleri kadar aşağıda sıralanmış çevresel faktörler de önemli roller oynar [7]: yazılımı (DMSO NG, MAK RT, Pitch p, FDK Detailed ) İşletim Sistemi (Windows, Linux) Yerel ve geniş alan ağı ortamları (LAN/ WLAN) Donanım platformları Network arayüz kartları Bir federenin performansı sadece kendisini değil tüm federasyonu etkileyebilir. Performansını etkileyen sebeplerin çokluğu gözönüne alındığında, HLA mimarisine uygun olarak geliştirilen dağıtık benzetim sistemlerinin entegrasyonun ve testlerinin de planlı bir süreç kapsamında yapılması gerektiği ortaya çıkmaktadır. Geliştirme ve entegrasyon safhalarının başlarında tespit edilemeyen hatalar, ileride geri dönülemez aksaklıklara sebep olabileceği gibi gittikçe daha büyüyen ve karmaşıklaşan projelerde sorunun kaynağının ve etkilerinin bulunmasını da oldukça zorlaştırır. 3. Test Seviyeleri ve Test Tipleri Yazılım sistemlerinde hataların tespitini, sınıflandırılmasını, tanımlanmasını ve raporlanmasını kolaylaştıracak şekilde test süreci seviyelendirilmelidir. Bu seviyelendirme, farklı çalışma gruplarının geliştirdiği benzetim sistemlerinin tümleşik bir şekilde çalışabilmesi için önem arzetmektedir. Bu çalışmada HLA tabanlı benzetim sistemleri için yazılım mühendisliği alanında kabul görmüş olan test seviyelerini içerek şekilde dört seviyeli bir test süreci önerilmektedir (Tablo 1). Tablo 1. Test seviyelerinde uygulanacak test tipleri Uygulanacak Test Tipi Model Testi Federe Testi Senaryo Testi Federasyon Testi 3.1. Model Testi Test Seviyesi Birim Test Birim / Entegrasyon Testi Entegrasyon Testi Sistem Testi Federe benzetim modelinin doğrulaması ve geçerlemesi (verification&validation) bu seviyede yapılır. Doğrulama işlevleri kapsamında, benzetimi yapılan sistemin modellenişi için yazılmış olan model kodunun beklenen isterleri karşıladığı ve kod standartlarına uygunluğu denetlenir. Geçerleme kapsamında ise gerçekleştirilen benzetim modelinin temsil ettiği sistem ile uyumluluğu değerlendirilir. Bu kapsamda aşağıdaki işlevler de yerine getirilmiş olur. Veri alan/veren fonksiyonlarda veri aralıklarının kontrolü (Boundary Test) Mesajlarda alınıp/gonderilen verilerin (tip) kontrolü (Type Checking) İstisna Yönetimi (Exception Handling) Birim testler, federeyi oluşturan modüllerden kaynaklanacak hataları azaltmayı hedeflediğinden yazılıma eklenen her bir yeni işlevsellik için bir veya birkaç birim test durumu gerekir. Birim testlerinin geliştirilmesi için çevik programlama kapsamında başarısı kanıtlanmış Test Yönelimli Geliştirme pratiğinin kullanılması yararlı olacaktır [8] Federe Testi Benzetim modelleri HLA mimarisinde federe adı verilen yazılım bileşenleri içine gömülmüştür. Federenin FOM a uygun bir arayüzü vardır. Bu arayüzün federenin benzetim modeline ve benzetim modelinin de arayüzü ile olan iletişiminin FOM a uygun olup olmadığı federe testi ile kontrol edilir. Federeyi test etmek amacıyla, test edilecek federenin yayınladığı nesne ve etkileşimlere abone olan ve abone olduğu nesne ve etkileşimleri yayınlayan bir test federesi (TF) kullanılır. Test federesinin, federasyonda bulunan test edilen federe dışındaki diğer tüm federeleri temsil ettiği düşünülür. Bazı yaklaşımlarda ise Test edilecek federe dışındaki her federe için bir test federesi kullanılır [9]. Federe Testi durumları hazırlanırken Test Edilecek Federe nin (TEF) işlevleri göz önüne alınarak bir test konfigürasyon dosyası ve her test durumu için bir test referans dosyası hazırlanır. Test federesi, bu konfigürasyon dosyasını yorumlayarak TEF e gerekli nesne ve etkileşimleri gönderir ve alır. Her test durumu

3 için hazırlanan referans dosyası ile Test Federesinin o test durumu için ürettiği aynı formattaki test sonuç dosyası karşılaştırılarak testin başarısı belirlenir. Şekil 1 de bir federe testinde yer alacak yazılım bileşenleri görülmektedir. TF, TEF in abone olacağı ve yayınlayacağı etkileşimler ile güncelleyeceği veya güncellenmesini takip edeceği tüm nesnelere sahiptir. Kısaca bu işlevleri yerine getirecek A, B ve C federelerini temsil eder. Test federesi yerine A, B ve C federeleri sisteme dahil edildiğinde tek fark, test verisi yerine gerçek verilerin kullanılacak olmasıdır. Sisteme yeni bir federe dahil olduğunda TEF ile TF de bu doğrultuda güncellenir ve TEF için federe testleri tekrarlanır. geçen bu dört federenin de federe testlerini geçmiş olması gerekmektedir. Şekil 2: K Senaryosu Testi Federe B Test Edilecek Federe (TEF) / Test Federesi (TF) Federe B Federe C Federe C Şekil 3: L Senaryosu Testi 3.3. Senaryo Testi Şekil 1: Federe Testi Federelerin bir arada çalışabildiklerini göstermek amacıyla, federasyonun sadece belli bir grup sistem işlevini kapsayan senaryolar temel alınarak entegrasyon testleri gerçekleştirilir. Bu sayede, testler sırasında farkedilen hataların hangi federe veya federelerden kaynaklandığı daha kolay tesbit edilebilmektedir. Bu seviyedeki testlerde en çok karşılaşılan sorun, federelerin FOM a uygun olmaması ya da aynı FOM u kullanmıyor olmalarıdır. Hata tesbiti için federeler arası etkileşimin kayıt altına alınması gerekebilir. Senaryo testlerinde test federesinin ürettiği etkileşim, nesne ve verilerin kullanılmayıp, gerçek federelerin etkileşim, nesne ve verilerinin kullanılması; federe testinde tespit edilemeyen birtakım hataların tespitini sağlar. Tutulan hata raporlarının sayısı gibi istatistiksel verilerle de görülmüştür ki senaryo testleri en fazla hatanın tespit edildiği test seviyesidir ve federelerde değişiklik yapmaları için çok fazla sayıda talep gönderilir. Bu nedenle, konfigürasyon yönetiminde dayanak noktası alınması (baseline) işleminin senaryo testlerinden sonra yapılması tavsiye edilir. Şekil 2 de görülen K senaryosunda,, ve Federe B federeleri yer almaktadır. Şekil 3 de görülen L senaryosunda ise,, ve Federe C federeleri yer almaktadır. Adı Senaryo testleri esnasında değişik federe gruplarıyla tekrarlanan test durumları, gözlemlenen hataların hangi federe veya federelerden kaynaklandığını tespit etmekte sistematik bir yol sağlamaktadır Federasyon Testi Bütün federelerin katıldığı bir federasyon oluşturulur ve federasyon için tanımlanan hedefleri gerçeklediği test edilir. Bu açıdan bakıldığında federasyon testi, Sistem Kabul Testi ne geçişi sağlar. Bu nedenle, test esnasında kullanılan verilerin gerçek veriler olması önem taşımaktadır. Senaryo testlerinde sistemin entegre bir şekilde çalışması ön planda iken federasyon testinde buna ilave olarak sistemden beklenen işlevlerin gözlenebilmesi beklenmektedir. Benzetim içeren bir sistemin işlevsel testlerini yapmak, gerçek sistemin davranışlarını ve değişik koşullardaki tepkilerini kapsayan geniş bir alan bilgisini gerekli kılar. Şekil 4 te görüldüğü gibi bir federasyon testinde, bütün federeler yer alır. Ayrıca varsa veritabanı, ftp sunucusu, lisans sunucusu gibi bileşenler de müşteriye teslim edileceği şekilde bulunmalıdır. Kısaca, federasyon testinde yer alacak yazılım ve donanım konfigürasyonu, proje bittiğinde müşteriye verilecek olan sistemle aynı olmalıdır. Bazı senaryo testleri sistemde yer alacak tüm federeleri içerebilir. Bu nedenle federasyon testlerinde büyük sürprizler beklenmez, hataların çoğunlukla bu aşamaya kadar elimine edildiği görülür. Federasyon testinde ise

4 daha çok entegrasyon ve performans problemleri incelenir. Sistemin saatlerce, hatta günlerce çalışabileceği senaryolar koşturulur ve dayanıklılık ölçülür. Sistem İsterleri Federe B Federe C Federasyon Hedeflerinin Federasyon İSTERLERİN BELİRLENMESİ Kavramsal Senaryoların Senaryo ÖN TASARIM 4. Test Tasarım Süreci Şekil 4: Federasyon Testi Dağıtık benzetim sistemlerinin testlerinin uygulanışında tabandan tepeye (bottom up) bir yapı izlense de test durumlarının tanımlanması esnasında tepeden tabana (top down) bir bakış gerekmektedir (Şekil 5). FEDEP sürecinde de olduğu gibi; bir federasyonun temel yapıtaşları olan federelerin işlevlerinin tam olarak belirlenebilmesi için önce federasyon hedeflerinin analiz edilmesi gereklidir. Bu nedenle, hedefler işlevsel özelliklerine göre gruplanarak kavramsal senaryo çalışması yapılır ve federeler ile aralarındaki ilişkiler belirlenir Federasyon Hedeflerinin Benzetimi yapılacak olan sistemin son kullanıcıları ile birlikte kullanıcı isterleri tanımlanır. Bu kullanıcı isterlerinden yola çıkılarak, alan uzmanlarının denetiminde federasyon hedefleri belirlenir. Bu hedef ve isterleri kapsayacak senaryolar oluşturulur. Federasyonun geliştirilmesinin ardından bu senaryolar netleştirilir ve test tasarımları yapılır. Tasarlanmış test durumlarının işletilmesi, sistemin tüm isterlerinin gerçeklendiğini gösterir Kavramsal Senaryoların Federasyon hedeflerinden yola çıkarak her biri belli bir grup federasyon işlevini içeren senaryolar oluşturulur ve bu senaryolarda rol alacak federeler belirlenir. Senaryoların belirlenmesi için BOM metodolojisinin temel alındığı çalışmalar yapılabilir [6]. Senaryoları oluşturan federeler arasındaki etkileşimlerden yola çıkarak senaryo test durumları tanımlanır. Senaryo testi durumları, entegrasyon problemlerini görmeye yönelik olmalıdır. Bu nedenle, olası bütün etkileşim ihtimallerini içeren bir test tasarımı yapılmalıdır. BOM senaryolarının belirlenmesi sona erdiğinde sistemde yer alacak federeler de ortaya çıkmış olur. Federe İşlevlerinin Federelerin Geliştirilmesi Şekil 5: Test tasarımı süreci 4.3. Federe İşlevlerinin Senaryolarda rol alan her bir federenin işlevleri belirlenir. Her federe için kendisinden beklenen işlevlere göre test durumları tasarlanır. Senaryo test durumları olası tüm etkileşimleri içerdiğinden federe test durumları, senaryo testlerinin test federesi kullanılarak gerçekleştirilmesiyle yapılabilir Federelerin Geliştirilmesi Federeler, işlevlerine uygun olarak modellenir. Geliştirilen modeller doğrultusunda federelerinin içermesi gereken bileşenler tanımlanır. Bir federenin geliştirilmesinin ardından her bir bileşeninin doğrulaması ve gerçek modele uygunluğunun geçerlemesi gerekir. 5. Entegrasyon Problemleri Federe Birim AYRINTILI TASARIM GELİŞTİRME Büyük çaplı bir dağıtık benzetim sisteminde performansı etkileyecek çok sayıda faktör vardır. Hataların tespitinin ve çözümünün olabildiğince erken yapılması çok önemlidir. Entegrasyon ve testlerde aşağıdaki noktalara dikkat edilmelidir: Bir bilgisayarda çalışacak federe sayısı Federenin veritabanı ve ftp bağlantısı varsa bağlantıların kontrolü a bağlantı için gerekli rid dosya ayarlarının kontrolü (Özellikle server ip, port ve fomdatareliable gibi ağ ve veri ayarları)

5 Üçüncü parti yazılımların ve sürücü ayarlarının bilgisayar performansına olan etkileri (Bir bilgisayarda ekran kartı varsayılan ayarlarının federe performasını önemli ölçüde düşürdüğü gözlenmiştir.) Ortam değişkenlerinin kontrolü Tüm federelerde aynı FOM un kullanılması (Federe testlerinde problem farkedilemezken, federasyon testlerinde beklenmedik durumlarla karşılaşılabilir.) Ağ ayarları (firewall, DNS ayarları vs.) Test ortamındaki ağın bağımsız olması, dışarıya herhangi bir şekilde bağlanmaması Yazılım lisans problemleri (Lisans sürelerinin dolması, lisans sunucuyla bağlantı) Federelerin ve diğer uygulamaların uzaktan başlatılması (Uzaktan başlatma için uygulama seçimi ya da geliştirilmesi ve bu yazılımın a etkileri) Yaşam döngüsü testleri (senaryo yükleme, koşum başlatma, koşumu duraklatma, koşumu tekrar başlatma, başka bir senaryo yükleme) 6. Sonuç Bu çalışmada, yüksek sadakatli dinamik modellerin ve gerçeğine yakın görselliğe sahip model arayüzlerinin bulunduğu geniş ölçekli bir dağıtık simülasyon projesinin entegrasyonu ve testleri için geliştirilen özgün süreç anlatılmış ve karşılaşılan problemler listelenmiştir. Yaklaşık 50 yüksek performanslı bilgisayarın, ses, görüntü ve veri yollarının, 20 civarında federenin, faal veritabanı, FTP ve sunucularının, çeşitli üçüncü parti yazılımların bulunduğu bir sistemin istenildiği gibi çalışması için yoğun bir entegrasyon ve test süreci gerçekleştirilmiştir. Her federe ve geliştirilen yazılım, federelerdeki modüllerin birim testinden başlayıp sistemin tümleşik şekilde çalışmasına kadar olan tüm kontrolleri içeren dört farklı seviyede detaylı olarak test edilmiştir. Bu seviyelendirme sayesinde, değişik kaynaklı sorunların tespiti ve analizi kolaylaşmış, getirilen sistematik çalışma yapısı ile tüm proje ekibinin geliştirme safhasından itibaren yapılması muhtemel hataları öngörmeleri ve önlem almaları da sağlanmıştır. Tüm federelerin entegrasyonu sonucunda karşılaşılan problemler de bu sürece uygun olarak elimine edilmiş, bir alt seviyedeki testi geçecek şekilde hataları düzeltilmemiş modüller daha karmaşık sistemlere dahil edilmemiştir. Hataların bir kısmının federasyon testlerine kadar çözülememesi, federe etkileşim ve nesne güncellemelerinin yeterince izlenememesinden kaynaklanmaktadır. Federe ve Senaryo testlerinde etkileşimleri izlemek amacıyla etkin bir loglama aracına ihtiyaç duyulmaktadır. Birim testlerin detayı konusunda yaratılmış kesin bir standardın olmayışı, federe testine girecek olan federelerin daha önce aynı seviyede test edilememelerine neden olabilmektedir. Ayrıca federe test konfigürasyon dosyalarının hazırlanması da yine federe alanına (domain) en hakim kişi olan geliştiriciyle beraber çalışmayı gerekmektedir. Birim testlerinin ve federe testlerinin kalitesini artırmak amacıyla çalışmalar yapılmalıdır. TÜBİTAK Marmara Araştırma Merkezi Bilişim Teknolojileri Enstitüsü nde modelleme ve benzetim alanında yapılan çalışmalarda ortaya çıkan özgün doğrulama ve geçerleme yaklaşımı ihtiyacının karşılanmasına yönelik çalışmalar devam etmektedir. 7. Kaynakça [1] Kuhl, F., Weatherly, R., Dahmann, J., Creating Computer Simulation Systems, Prentice Hall PTR, [2] Duman, İ., Savaşan, H., Şahin, İ., Bir Modelleme ve Simülasyon Standardı Olarak HLA ve Simülasyon Uygulamalarında Kullanımı, Dz.K.K. lığı Araştırma Merkezi Komutanlığı (ARMERKOM) Yayınları, [3] Balcı, O., Verification, Validation, And Certification of Modeling And Simulation Applications, Winter Simulation Conference (WSC), ABD, [4] IEEE Standard (2003) IEEE recommended practice for high level architecture (HLA) Federation Development & Execution Process (FEDEP), 23 April [5] Simulation Interoperability Standards Organization (SISO) Base Object Model Product Development Group, Base Object Model (BOM) Template Specification, SISO-STD , 31 March [6] Timar, Y., Taşdelen, İ., Akgün, S., Dikenelli, O., Bıkmaz, İ., Using BOM in Conceptual Modeling of Distributed Simulation Projects, Simulation Interoperability Workshop (SIW), ABD, [7] Knight, P., Corder, A., Liedel, R., Giddens, J., Drake, R., Jenkins, C., Agarwal, P., Evaluation of Run Time Infrastructure () Implementations, [8] Erdogmus, H., Morisio, M., Torchiano, M., On the Effectiveness of the Test-First Approach to Programming, IEEE Transactions On Software Engineering, Vol. 31, No. 1, January [9] Tufarolo, J., Nielsen, J., Symington, S., Weatherly, R., Wilson, A., Ivers, J., Hyon, T.C., Automated Distributed System Testing: Designing an Verification System, Winter Simulation Conference (WSC), ABD, 1999.