Terminology as the Basis for Building Engineering Feature-based Models

186 Ricardo Eito Brun A terminológia mint az építés alapja Engineering Feature-based Models doi.org/10.35321/term27-08 A terminológia mint az építés alapja Engineering Feature-based Models RicaRdo Eito BRun Universidad Carlos III de Madrid ÖSSZEFOGLALÓ A műholdműveletek különböző eszközök együttes használatát igénylik a mérnöki tevékenységek támogatására és az űreszköz irányítására. Ezt a kommunikációt a Monitoring and Control System (MCS), azaz a megfigyelőés vezérlőrendszer kezeli, amely telemetriai adatokat fogad az űreszköztől, és távparancsokat bocsát ki a műhold helyzetének és repülési pályájának fenntartása érdekében. Ezeket az összetett rendszereket nyílt platformokként fejlesztik ki, amelyek kiterjeszthetők és testre szabhatók a küldetésspecifikus követelmények és célkitűzések támogatása érdekében. Általános szabályként megállapítható, hogy ezek a szoftveralkalmazások jó jelöltek a változékonysági mechanizmusok strukturált, tervezett módon történő megvalósítására, továbbá funkcionalitásuk alkalmas a jellemzőalapú modellezési technikák alkalmazhatóságának elemzésére. Ez a tanulmány a terminológiaelemzés alkalmazását mutatja be egy olyan jellemzőmodell létrehozására, amely támogatja az ilyen típusú, szoftveralapú rendszerek követelményelemzését. KULCSSZAVAK: Műszaki terminológia, Jellemzőalapú modellek, Repülőgépés űripari mérnökség, Terminuskivonás ANOTÁCIÓ A műholdműveletekhez különféle eszközökre van szükség, amelyek biztosítják a zökkenőmentes mérnöki munkát és az űreszköz irányítását. Ezt a kapcsolatot a Megfigyelési és irányítási rendszer (SKS) vezérli, amely telemetriai adatokat fogad az űreszköztől, és távparancsokat ad a műhold helyzetének és pályájának fenntartása érdekében. Ezeket az összetett rendszereket nyílt platformokként fejlesztették ki, amelyek az adott küldetés követelményeihez és céljaihoz igazodva bővíthetők és alakíthatók. Állíthatjuk, hogy általában ezek az alkalmazások strukturáltan és tervszerűen használhatók a változatossági mechanizmusok bevezetésére, funkcionalitásuk pedig lehetővé teszi a jellemzőalapú modellezési módszerek alkalmazási lehetőségeinek elemzését. Ez a cikk a terminológiai elemzés alkalmazását írja le egy olyan jellemzőmodell létrehozására, amely támogatja az ilyen típusú szoftverrendszerek követelményeinek elemzését. KULCSSZAVAK: műszaki terminológia, jellemzőmodellek, repüléstechnikai mérnöki tudomány, terminusfelismerés 187Terminológia | 2020 | 27 1. INTROduCTION A NASA szójegyzéke a műholdakat a következőképpen definiálja: „szabadon repülő objektum, amely a Föld, egy másik bolygó vagy a Nap körül kering.1” A műhold olyan űreszköz, amely egy másik égitest tömegközéppontja körül szabályos, egyértelműen meghatározott pályán halad (Garner 1996: 4). Az első mesterséges műholdak – a Sputnik 1 1957. október 4-i és az Explorer 1 1958. január 31-i felbocsátása – óta számos, különböző célú műholdküldetést indítottak: csillagászati kutatást, kommunikációs és navigációs szolgáltatások biztosítását, Föld-megfigyelést, felderítést és tudományos küldetéseket. A műholdak összetett űrrepülési rendszerek, amelyek földi és űrbeli elemekből állnak: az űreszközt egy földi irányítóelemnek kell működtetnie, és kapcsolatban kell maradnia vele. Napjainkban a tudományos fejlődés és a felhasználóknak nyújtott szolgáltatások a műholdaktól és a műhold-konstellációktól függenek. Releváns példák közé tartozik a Hubble űrtávcső (HST), az olyan navigációs rendszerek, mint a GPS (Global Positioning System), a GLONASS és az európai Galileo, az UARS (Upper Atmosphere Research Satellite), illetve a GOES (Geostationary Operational Environment Satellite). Az 1957 óta felbocsátott műholdak teljes száma – az amerikai SSN2-katalógus szerint – megközelíti a 18200-at; az uNOOSA 2017-es, a világűrbe felbocsátott objektumok jegyzéke szerint jelenleg 4635 műhold kering a bolygó körül, ami az előző évhez képest 357 műholdas (8.95%-os) növekedést jelent3. E cikk célja annak bemutatása, hogy szükség van a terminológiamenedzsment és -kinyerés alkalmazására a műholdak megfigyelésére és irányítására használt szoftveralkalmazások funkcióit leíró fogalmak rendszerezésére szolgáló jellemzőalapú modellek fejlesztésének támogatásához. A műholdakat rendeltetésük és pályatípusuk szerint osztályozzák. A rendeltetés arra utal, hogy a műhold milyen szolgáltatásokat hivatott nyújtani. A pályát illetően különbséget tesznek az alacsony Föld körüli pálya (LEO), a közepes Föld körüli pálya (MEO) és a geostacionárius pálya (GEO) között. A tudományos és Föld-megfigyelési célokra használt LEO-műholdak elliptikus pályán keringenek; mivel a földi állomásokról való láthatóságuk korlátozott, az adatokat a fedélzeten tárolják, majd továbbítják a földre 1 Lásd: https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [hozzáférés: 2020-08-01]. 2 Az Egyesült Államok Űrmegfigyelő Hálózata felelős a Föld körül keringő mesterséges objektumok észleléséért, nyomon követéséért, katalogizálásáért és azonosításáért. A katalógus elérhető itt: https://www.space-track.org/#/ssr [hozzáférés: 2020-08-01]. 3 Az Egyesült Nemzetek Szervezetének Világűrügyi Hivatala. Lásd: 188 Ricardo Eito Brun A terminológia mint az építés alapja Engineering Feature-based Models https://www.pixalytics.com/sats-orbiting-earth-2017/ az állomásokra, amikor a repülőgép láthatóvá válik. A GEO-műholdakat távközlési és meteorológiai célokra használják; A távközlési műholdak rádiófrekvenciás (RF) jeleket fogadnak a Földről, felerősítik, eltolják a frekvenciájukat, majd visszasugározzák őket a Földre. Az Egyenlítő felett 36 000 km-rel keringenek (ugyanabban a síkban), forgásuk pedig szinkronban van a Föld forgásával, így mindig ugyanazon egyenlítői pont felett maradnak)4. A műholdakhoz hasonlóan a mélyűri tudományos küldetéseknek is hasonló felügyeletre és vezérlésre van szükségük a távparancsok és a telemetria fogadásához. A műholdküldetéseknek kijelölt személyzetre van szükségük a műhold állapotának és helyzetének valós idejű, folyamatos nyomon követéséhez. A küldetésirányítás az üzemeltetési mérnökök által az indítást követően, szoftveralkalmazások segítségével végrehajtott feladatok összessége, amely magában foglalja a földi és az űrszegmens közötti adatcserét a műhold fedélzeti alrendszerei állapotának felügyelete és vezérlése céljából. A tudományos küldetések során szükség van a műhold hasznos terhéből származó információk fogadására is, és a küldetésirányítás során végzett feladatok közé tartozik a telemetria fogadása és elemzése, a távparancsok küldése, valamint a követés. A telemetria a műholdról a deliver it to the end-users (scientific community). Typical functions exFöldre továbbított adat, amely tájékoztatást ad a műhold és alrendszerei állapotáról és körülményeiről. A távparancsok a földről az űrjárműhöz továbbított utasítások annak konfigurálására és üzemeltetésére. (Uhlig, Sellmaier és Schmidhuber 2015: 232). A nyomon követés és az állomástartás, más néven távolságmérés, a repülési útvonal és a pozíció RF-technológiák és jelek segítségével történő megfigyeléséből és meghatározásából áll. Szoftverfejlesztési szempontból a műholdvezérlés különböző alkalmazásokat és eszközöket igényel a repülési dinamikához, a küldetéstervezéshez, a telemetriához és a távparancsok küldéséhez, a hálózatvezérléshez és -útválasztáshoz, valamint az ezek közötti interfészekhez. Ez az összetettség arra késztette az űrügynökségeket, hogy különböző megoldásokat kínáljanak. Az MCS-szoftver fejlesztésének egyik legjelentősebb mérföldköve az ESA Földi Rendszerek Mérnöki Osztályának döntése volt, hogy kifejleszt és licencel az európai ipar számára egy MICONYS® néven forgalmazott szoftveralkalmazás-készletet 4 GEO-műhold korlátozott térbeli területen oszlik el. A pályapozíciókat a Nemzetközi Távközlési Unió (ITu) osztja ki az ütközések elkerülése érdekében; ez a kockázat az űrszemét témájához kapcsolódik, amely napjainkban egyre nagyobb figyelmet kap. 189Terminologija | 2020 | 27 (Misszióirányító rendszer). A MICONYS és annak SCOS-2000® komponense valószínűleg a legismertebb példái az ESA szoftverfejlesztési, innovációs és technológiatranszfer-politikájának (Kaufeler, Jones and Karl 2001). A SCOS-2000 támogatja a távparancsadást, a telemetria fogadását, a megjelenítést és az archiválást. A SCOS-2000 az ESA által korábbi, hasonló rendszerek – az MSSS, a SCOS-1 és a SCOS-2 – fejlesztése és üzemeltetése során szerzett tapasztalat eredménye volt. Az ESA jelenleg az új MCS-rendszert fejleszti, amelynek célja, hogy a jövőben felváltsa a SCOS-2000-et. Neve European Ground Systems – Common Core (EGS-CC). A SCOS-hoz hasonlóan a projekt célja egy olyan közös infrastruktúra kifejlesztése, amely modern technológiák és szolgáltatásorientált architektúrák alkalmazásával támogatja az űrmissziók megfigyelését és vezérlését az indítás előtti és utáni szakaszokban (Pecchioli et al. 2012). Az EGS-CC fejlesztése nem kizárólag az ESA felelőssége: európai nemzeti űrügynökségek (CNES, UK Space Agency és DLR), valamint ipari vállalatok (AIRBUS Defence and Space, Thales Alenia Space és OHB Systems) is részt vesznek a projektben. Az ESA projektjein kívül más kezdeményezések is irányulnak egy általános célú MCS-szoftverrendszer kifejlesztésére. A NASA hasonló projekteket is végrehajtott, amelyek többsége házon belüli fejlesztés volt. A Goddard Űrrepülési Központ két rendszert fejlesztett ki, az ITOS-t és az ASIST-et, olyan küldetések kezelésére, mint a WMAP (Wilkinson Microwave Anisotropy Probe), az IMAGE (Imager for Magnetopause-to-Aurora Global Exploration), az EO-1 (Earth Observing 1), az ST-5 (Space Technology 5), az SdO (Solar Dynamics Observatory) vagy az LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). Mindezekben az esetekben egy összetett rendszerrel van dolgunk, amelynek különböző funkciókat kell megvalósítania; ezek aktiválhatók vagy sem a műhold és a küldetés jellemzőitől függően. Ennek következtében ezek a szoftverintenzív rendszerek jó jelöltek termékvonalak és jellemzőalapú modellezési technikák alkalmazásával történő fejlesztésre, amelyek a fogalmak világos és jól szervezett szerveződésére támaszkodnak a tartomány és a rendszer szükséges képességeinek megértése érdekében. 2. JELLEMZŐALAPÚ MODELLEZÉS A FOGALMAK SZERVEZÉSEKÉNT A jellemzőalapú modellezés a szoftvertermékvonal-mérnökségben alkalmazott technikák egyike; ez egy újrafelhasználható szoftverprogramok építésére szolgáló diszciplína, amely a kilencvenes évek végén vált népszerűvé. Az SPLE célja újrafelhasználható komponensek és artefaktumok létrehozása, 190 Ricardo Eito Brun A terminológia mint az építés alapja Engineering Feature-based Models amelyek később kombinálhatók egy adott ügyfél és kontextus igényeihez igazodó termékek felépítéséhez. Az SPLE-ben szerzett tapasztalatokat a szakmai és az akadémiai szakirodalom széles körben dokumentálja. Capilla (2013) több olyan esettanulmányt is bemutatott, amelyekben az SPLE-t sikeresen alkalmazták: a Boeing operatív, küldetéskritikus repülési programjai az avionikai és pilótafülke-funkciókhoz, a Bosch benzinüzemű rendszerek motorvezérlő szoftvere, a Hewlett Packard nyomtatószoftvere, a Toshiba energiatermelő és -átviteli berendezései, valamint a General Motors hajtásláncokhoz készült vezérlőszoftvere. Az Apel és munkatársai (2013: 9) szerint a szoftvertermékcsaládok (SPL) előnyei közé tartozik a szoftvertermékeknek az ügyfelek egyedi igényeihez való igazítása, a költségek csökkentése – mivel az új termékek létrehozásához újrafelhasználható eszközök halmaza különböző módokon kombinálható –, valamint a jobb minőség és a piacra kerülési idő rövidülése. A jellemzők és a jellemzőalapú modellezés releváns fogalmak az SPL fejlesztésében. Az ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary általános definíciót ad a jellemzőkre, amelyet az IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation szabványból vett át: „Egy rendszer valamely elemének megkülönböztető jellemzője. MEGJEGYZÉS: magában foglal funkcionális és nem funkcionális attribútumokat is, például a teljesítményt és az újrafelhasználhatóságot.” Kang és Lee (2013, 28) a jellemzőket a következőképpen definiálják: „absztrakt fogalmak, amelyek hatékonyan támogatják a kommunikációt egy termékcsalád különböző érdekelt felei között, ezért természetes és intuitív, hogy az emberek a termékcsaládok közös és változó jellemzőit jellemzők formájában fejezzék ki.” A jellemzők különböző célokat szolgálnak a termékötlet kialakításának és fejlesztésének folyamatában. Eszközként szolgálnak a termékjellemzők kommunikálására, és támogatják a követelmények azonosítását; ők egyben azok a fogalmak is, amelyek a tervezési és megvalósítási döntéseket irányítják. Egy termékvonal fejlesztése két egymást kiegészítő életciklusból áll: • tartománytervezés, valamint • alkalmazástervezés. Az IEEE 1517-2010 szabvány a tartománytervezést a következőképpen határozza meg: „Életciklus, amely egy termékvonal közös jellemzőinek és változatosságának meghatározására és kezelésére szolgáló folyamatok összességéből áll. a tartománytervezés elemzi egy termékvonal tartományát, és újrafelhasználható termékösszetevők együttesét fejleszti ki. Ezek a termékösszetevők magukban foglalják a szoftverkövetelményeket, a tervezési elemeket, a teszteseteket és 191Terminologija | 2020 | 27 egyfajta követelménytervezést a teljes procedures, user documentation, etc. domain analysis can be seen as a termékvonal számára, beleértve az előre látható változatosság azonosítását is. A fő artefaktum a vonalon belül generált termékeket. by domain analysis is the feature model that will specify and describe the A jellemzőmodellezés egy diagramkészítési technika, amelyet a kilencvenes években vezettek be az FOdA (Feature-Oriented Domain Analysis, jellemzőorientált tartományelemzés) módszertanával. Az FOdA primitíveket biztosított a strukturális kapcsolatok (kompozíció, általánosítás és specializáció), az opcionálisság, az alternatív jelleg és a kölcsönös függőségek ábrázolására. Később különböző szerzők áttekintették (Kang és Lee 2013: 30–31). A jellemződiagramok a jellemzőmodellek vizuális reprezentációi, amelyekben a jellemzőket egy hierarchikus fában dobozok jelenítik meg. Minden csomóponthoz egy, a jellemző nevét tartalmazó címke kapcsolódik. A jellemzők hierarchikus elrendezése szülő–gyermek kapcsolatokat hoz létre. Ha egy gyermekjellemzőt kiválasztanak, akkor a szülőjét is ki kell választani. A diagramok különbséget tehetnek a kötelező és az opcionális jellemzők között, és azonosíthatják a jellemzők érvényes kombinációit. Különösen a jellemződiagramok a következőket ábrázolhatják: • Absztrakt jellemzők, amelyek a fában lévő jellemzők rendszerezésére szolgálnak, de nincsenek implementációs artefaktumokhoz kötve. Szürke dobozokkal vannak ábrázolva. • Konkrét jellemzők, amelyek implementációs artefaktumoknak felelnek meg, és fehér dobozokkal vannak ábrázolva. • Kötelező jellemzők, amelyek dobozuk felső szegélyének tetején kitöltött ponttal rendelkeznek. • Opcionális jellemzők, amelyek dobozuk felső szegélyének tetején kitöltetlen ponttal rendelkeznek. • Annak szükségessége, hogy egy adott szülő gyermekjellemzői közül csak egyet válasszunk (kizáró VAGY, XOR vagy sok közül egy). A szülőjellemző dobozának alsó szegélyénél üres ívvel van ábrázolva. • Annak lehetősége, hogy egy adott szülő több gyermekjellemzője közül egynél többet válasszunk (VAGY vagy sok közül néhány). A szülőjellemző dobozának alsó szegélyénél kitöltött ívvel van ábrázolva. • a jellemzők közötti függőségek, amelyeket szöveges megjegyzésekkel ellátott nyilak ábrázolnak. 192 Ricardo Eito Brun A terminológia mint az építés alapja Engineering Feature-based Models Az alábbi diagram egy tipikus jellemződiagramot mutat be a fent ismertetett jelölésekkel: 1. ábra. Jellemződiagramozási példa (Forrás: Gargantini 2015) Egy jellemzőmodellnek a diagramon túl további információkat is tartalmaznia kell. Apel és mtsai (2013: 27) jelzik ezen adatok hozzáadásának lehetőségét: • „Egy jellemző leírása és a hozzá tartozó követelmények halmaza. • Kapcsolat más jellemzőkkel, különösen a hierarchia, a sorrend és a csoportosítás. • Külső függőségek, például a szükséges hardveres erőforrások. • Érdekelt felek. • Egy jellemző megvalósításának becsült vagy mért költsége. • Stb.” A műholdirányításhoz használt szoftveralkalmazások funkcionális jellemzőit reprezentáló jellemzőmodell kidolgozásának a tartományt alkotó fogalmak világos megértéséből és modellezéséből kell kiindulnia. E célból a terminológiával és terminográfiával kapcsolatos tevékenységek, a terminusok, fogalmak és azok kapcsolatai azonosítása biztosítják a célszövegbeli modell felépítésének alapját. 193Terminologija | 2020 | 27 3. A MUNKA MÓDSZERTANA A javasolt jellemzőalapú modell a következő lépések alapján készült el: • Az e területen publikált szakmai és tudományos szakirodalom azonosítása és áttekintése. Ez magában foglalja az olyan szervezetek, mint az ESA (Európai Űrügynökség) vagy a NASA (Nemzeti Repülési és Űrhajózási Hivatal) által vezetett repülési projektekben követett megközelítéssel kapcsolatos információk keresését. • A vizsgált szakirodalom alapján szójegyzék kidolgozása terminológiakezelési technikák alkalmazásával, a terminusokra, a közöttük fennálló kapcsolatokra, a dokumentumokban azonosított definíciókra, valamint arra a kontextusra vonatkozó információk rögzítésére, amelyben a terminusokat használják. • A műholdak megfigyelését és vezérlését szolgáló szoftveralkalmazások által kínált funkciókat reprezentáló, jellemzőalapú modell létrehozása a szójegyzék alapulvételével. A kifejezések azonosításához felhasznált bemenetek között szerepelt a kiválasztott terméket leíró műszaki dokumentumok egy része: használati útmutatók, fehér könyvek és képzési anyagok. A jellemzőmodell a jellemzők hierarchikus fája, amelyben a jellemzők kötelezőként vagy opcionálisként the case of the software application under analysis, besides the identificavannak megjelölve, és függőségek állnak fenn közöttük. Az opcionális és kötelező jellemzők azonosítása során további termékvonal-változékonysági követelményeket azonosítottak. Különösen, az elemzett szoftver által támogatott funkciók némelyike a meglévő kód felülírását vagy testreszabását igényli. E változási esetek azonosítását olyan szakértők támogatásával végezték, akik ilyen típusú szoftveralkalmazások fejlesztésével és testreszabásával foglalkoznak. Az információk összegyűjtése céljából személyes interjúkat készítettek. A jellemzőmodell és a diagramok létrehozásához kiválasztott eszköz a FeatureIDE5. Ez egy Java és Eclipse alapú, nyílt forráskódú eszköz, amelyet a Otto-von-Guericke-Universität Magdeburg munkatársai fejlesztettek ki. A FeatureIDE segítségével grafikus szerkesztő használatával lehet feature-modellt létrehozni, a feature-öket kötelezőként, opcionálisként vagy absztraktként megjelölni, valamint felépíteni a hierarchikus fát. A feature-modell felépítése után különböző konfigurációkat hozhat létre: a célalkalmazás előállításához használt feature-ök kiválasztásait5 Lásd: https://FeatureIdE.github.io/. Utolsó ellenőrzés: 01-03-2018. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models forráskódját. sajnos az eszköz nem biztosít lehetőséget terminusok vagy terminológiai egységek kezelésére, ezért kiegészítő eszközök használata szükséges. 2. ábra. FeatureIDE (a szerző készítette) 4. AZ EREDMÉNYEK ÉS A MEGVITATÁSOK BEMUTATÁSA Ez a szakasz a Küldetésirányító Rendszerek (MCS) szoftveralkalmazásai jellemzőmodelljének egyik szakaszát foglalja össze. A dokumentumokból kinyert fogalmak elemzése a rendszerfunkcionalitások ezen területek szerinti rendszerezéséhez vezetett: • Asztali környezetés munkamenet-kezelés, amely biztosítja a bejelentkezés, a munkamenet indítása és a különböző alkalmazások elindításának funkcióit. Több műhold kezelése esetén a felhasználó válthat a műholdak munkaterületei között. • Telemetriai lánc, amely magában foglalja a telemetria feldolgozását, a riasztáskezelőt és a telemetria megjelenítését.