Aaltomuoto-ohjelmiston arkkitehtuurin suunnitteleminen yhteensopivaksi OMNeT++-simulaatioympäristöön sekä laiteympäristöön

Abstract

Simulaatiota hyödynnetään ohjelmistokehityksessä vuosi vuodelta yhä enemmän. Simulointikeinoja haetaan alan tekijöiden toimesta jatkuvasti. Simulaatioympäristössä ohjelmiston toiminnalle kuitenkin esitellään aivan uudenlaisia haasteita. Haluttaisiin, että aikaa ja resursseja ei käytetä ohjelmiston uudelleenkirjoittamiseen pelkästään simuloinnin vuoksi.

Tässä työssä käsiteltiin aaltomuoto-ohjelmiston ohjelmistoarkkitehtuurin yhteensopivuutta OMNeT++-simulaatioympäristöön. OMNeT++ on avoimen lähdekoodin simulaatioympäristö, joka on suunniteltu verkostojen ja tiedonsiirron simulointia varten. Aaltomuoto-ohjelmisto on ohjelmistokokonaisuus, joka on tyypillisesti suunniteltu tiedonsiirtoon ohjelmistoradioalustalle. Simuloitavan aaltomuoto-ohjelmiston suunnittelussa ei ollut huomioitu simulointia, joten epäyhteensopivuudet olivat oletettuja. Löydetyt epäyhteensopivuudet käsiteltiin tarkasti ja niitten pohjalla olevat syyt tarkasteltiin. Ratkaisut epäyhteensopivuuksiin halutaan ottaa huomioon ja soveltaa ohjelmiston arkkitehtuuriin jo suunnitteluvaiheessa.

Aaltomuoto-ohjelmiston tuominen simulaatioympäristöön estyi ohjelmistoarkkitehtuurillisten epäyhteensopivuuksien aiheuttamien ongelmien vuoksi. Aaltomuodon C++-ohjelmistokomponenttien rakenteen vuoksi, joiden toiminnassa hyödynnettiin singleton-menetelmää, ohjelmistojen yhteensopivuus todettiin mahdottomaksi ilman refaktorointia. Simulaatioympäristössä ajettavat ohjelmistot pakotetaan olemaan ajossa yksittäisessä prosessissa, jonka avulla simulaation toiminta mahdollistetaan. Täten samalla kuitenkin estetään aaltomuodon toiminta simulaatiossa, sillä aaltomuoto-ohjelmiston ohjelmistoarkkitehtuuri ei ole suunniteltu ajettavaksi yhdessä prosessissa.

Yksi työssä ehdotetuista ohjelmistoarkkitehtuurillisista rakenteista on konttirakenne, jossa ohjelmiston ydintoiminnalta abstraktoidaan yhteydet muille ohjelmistokomponenteille ympäröimällä ohjelmiston toiminta kontilla. Kontti muodostuu yhteysrajapinnoista ohjelmiston ulkopuolelle. Konttiarkkitehtuuria soveltamalla suunnitteluvaiheessa ohjelmiston toiminta voidaan pitää irrallisena ohjelmiston ajoympäristöstä, jolloin ohjelmiston yhteensopivuutta erilaisiin ajoympäristöihin, kuten simulaatioympäristöön, saadaan parannettua.

Työssä todettiin, että ohjelman simulointiin vaikuttaa laaja määrä ohjelmistoarkkitehtuurillisia tekijöitä. OMNeT++:n simulaatiokernelin toiminta asettaa useita pakotteita simuloitavalle ohjelmistolle, joita on hankala kiertää silloin, kun ohjelmisto on jo toteutettu. Vaikuttavimmat rajoitteet olivat singleton-menetelmän hyödyntäminen ja verkkopistokerajapintojen käyttäminen ohjelmistossa. Täten, löydettyjä ongelmallisia ohjelmistoarkkitehtuurillisia päätöksiä on vältettävä jo ohjelmiston suunnitteluvaiheessa, jotta ylimääräiseltä työltä säästytään.

Simulating is used for software development and testing more and more every year. There is a constant ongoing search for new innovative ways to benefit from simulation in software development. However, a simulation environment introduces several new types of challenges for the simulated software, especially if the software is originally designed to be operated on a structurally different platform. The end goal is to use as few resources as possible but achieve compatibility for the simulated software and simulation environment so that simulation results can be obtained. In this thesis, the compatibility between a waveform software and the OMNeT++ simulation environment was researched. The waveform software has not been designed with simulating in mind, so factors affecting compatibility were to be expected. These factors were examined carefully and the root causes behind them investigated. If possible, the problematic factors should be avoided in the future by designing the software architecture to take them into account. Software architecture models preventing the discovered problematic factors were developed to alleviate the problems. Importing the waveform software into OMNeT++ was prevented when problematic design patterns used in the C++ code of the waveform software could not be avoided. The single most problematic design pattern used was the dreaded singleton-pattern, which effectively rendered the software impossible to simulate without major structural refactoring. Software running in simulation environment is forced to run in a single process, which is necessary due to the structure of the OMNeT++ simulation kernel. As the waveform software was designed to be used exclusively in hardware, the used design patterns caused compatibility issues when used in the simulation environment. The discovered problematic factors affecting compatibility should be avoided during the design phase of the software architecture. This saves the developers from having to do additional work to be able to simulate the software effectively. One of the suggested architectural design patterns is the container architecture, in which the connections of the software to external components should be abstracted by surrounding the core functionality of the software with a container. The container is formed of interface classes connecting the software to external components. In the end, the factors affecting compatibility between the waveform software and the simulation environment were too sizeable to overcome without any refactoring. The functionality of the OMNeT++ simulation kernel sets restraints for the software to be simulated that are difficult to overcome when the functionality of the software has already been implemented. These restraining factors include the use of the singleton design pattern and network socket interfaces connecting software components. The problematic software architecture factors should be avoided during the design phase so that no additional work needs to be done later.