Terminology as the Basis for Building Engineering Feature-based Models

186 Ricardo Eito Brun Terminologia jako podstawa budowy Engineering Feature-based Models doi.org/10.35321/term27-08 Terminologia jako podstawa budowy Engineering Feature-based Models RicaRdo Eito BRun Uniwersytet Karola III w Madrycie STRESZCZENIE Operacje satelitarne wymagają łącznego wykorzystania różnych narzędzi wspierających działania inżynieryjne i kontrolujących statek kosmiczny. Komunikacją tą zarządza System Monitorowania i Kontroli (MCS), który odbiera dane telemetryczne ze statku kosmicznego i wysyła telekomendy w celu utrzymania orientacji oraz toru lotu satelity. Te złożone systemy są opracowywane jako otwarte platformy, które można rozszerzać i dostosowywać w celu spełnienia wymagań i realizacji celów właściwych dla danej misji. Ogólnie rzecz biorąc, można stwierdzić, że te aplikacje programistyczne są dobrymi kandydatami do wdrażania mechanizmów zmienności w uporządkowany i planowy sposób oraz że ich funkcjonalność dobrze nadaje się do analizy wykonalności zastosowania technik modelowania opartego na cechach. W niniejszym artykule opisano zastosowanie analizy terminologicznej do budowy modelu cech wspierającego analizę wymagań dla tego typu systemów opartych na oprogramowaniu. SŁOWA KLUCZOWE: Terminologia techniczna, Modele oparte na cechach, Inżynieria lotnicza i kosmiczna, Ekstrakcja terminologii ANOTACIJA Do operacji satelitarnych potrzebne są różnorodne narzędzia, służące zapewnieniu sprawnej pracy inżynieryjnej i sterowaniu statkiem kosmicznym. Łącznością tą zarządza system obserwacji i kontroli (SKS), który otrzymuje dane telemetryczne ze statku kosmicznego i wysyła telekomendy w celu utrzymania położenia satelity oraz jego trajektorii lotu. Te złożone systemy są tworzone jako otwarte platformy, które można rozszerzać i dostosowywać do wymagań i celów konkretnej misji. Możemy stwierdzić, że zazwyczaj aplikacje te mogą być wykorzystywane do strukturalnego i planowego wdrażania mechanizmów zmienności, a ich funkcjonalność umożliwia analizę możliwości zastosowania metod modelowania cech. W niniejszym artykule opisano wykorzystanie analizy terminologicznej do stworzenia modelu cech wspierającego analizę wymagań dla tego typu systemów programowych. SŁOWA KLUCZOWE: terminologia techniczna, modele cech, inżynieria lotnicza, rozpoznawanie terminów 187Terminologija | 2020 | 27 1. INTROduCTION Słownik NASA definiuje satelity jako: „swobodnie poruszający się obiekt, który krąży wokół Ziemi, innej planety lub Słońca.1” Satelity są rodzajem statków kosmicznych poruszających się po regularnej, jasno określonej orbicie wokół środka ciężkości innego ciała niebieskiego (Garner 1996: 4). Od wystrzelenia pierwszych sztucznych satelitów – Sputnika 1 4 października 1957 r. i Explorera 1 31 stycznia 1958 r. – wystrzelono dużą liczbę satelitów w ramach misji o różnych celach: badań astronomicznych, zapewniania usług komunikacyjnych i nawigacyjnych, obserwacji Ziemi, rozpoznania oraz misji naukowych. Satelity są złożonymi systemami lotniczo-kosmicznymi, składającymi się z elementów naziemnych i kosmicznych: statek kosmiczny musi być obsługiwany przez element sterujący na Ziemi i pozostawać z nim w kontakcie. Obecnie postęp naukowy i usługi dla użytkowników zależą od satelitów i konstelacji satelitów. Do istotnych przykładów należą Kosmiczny Teleskop Hubble’a (HST), systemy nawigacyjne, takie jak GPS (Global Positioning System), GLONASS i europejski Galileo, UARS (Upper Atmosphere Research Satellite) lub GOES (Geostationary Operational Environment Satellite). Łączna liczba satelitów wystrzelonych od 1957 roku – według katalogu US SSN2 – jest bliska 18200; Index of Objects Launched into Outer Space agencji uNOOSA z 2017 roku podaje, że 4635 satelitów obecnie orbituje wokół planety, co oznacza wzrost o 357 satelitów (8.95%) w porównaniu z poprzednim rokiem3. Celem niniejszego artykułu jest wykazanie potrzeby zastosowania zarządzania terminologią i jej ekstrakcji w celu wsparcia opracowywania modeli opartych na cechach, służących organizowaniu pojęć opisujących funkcje aplikacji programowych wykorzystywanych do monitorowania i kontroli satelitów. Satelity klasyfikuje się według przeznaczenia i rodzaju orbity. Przeznaczenie odnosi się do usług, które satelita ma świadczyć. W odniesieniu do orbity rozróżnia się niską orbitę okołoziemską (LEO), średnią orbitę okołoziemską (MEO) oraz orbitę geostacjonarną (GEO). Satelity LEO – wykorzystywane do celów naukowych i obserwacji Ziemi – poruszają się po orbicie eliptycznej; ponieważ ich widoczność ze stacji naziemnych jest ograniczona, dane są przechowywane na pokładzie i przesyłane na Ziemię 1 Zob. https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [dostęp: 2020-08-01]. 2 Amerykańska Sieć Nadzoru Kosmicznego odpowiada za wykrywanie, śledzenie, katalogowanie i identyfikację sztucznych obiektów orbitujących wokół Ziemi. Katalog jest dostępny pod adresem: https://www.space-track.org/#/ssr [dostęp: 2020-08-01]. 3 Biuro Narodów Zjednoczonych ds. Przestrzeni Kosmicznej. Zob. 188 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models https://www.pixalytics.com/sats-orbiting-earth-2017/ stacje, gdy statek powietrzny staje się widoczny. Satelity GEO są wykorzystywane do celów telekomunikacyjnych i meteorologicznych; Satelity telekomunikacyjne odbierają sygnały o częstotliwości radiowej (RF) z Ziemi, wzmacniają je, przesuwają ich częstotliwość i transmitują je z powrotem na Ziemię. Orbitują 36 000 km nad równikiem (w tej samej płaszczyźnie), a ich obrót jest zsynchronizowany z obrotem Ziemi, dzięki czemu cały czas pozostają nad tym samym punktem równika)4. Podobnie jak satelity, naukowe misje kosmiczne również wymagają podobnego monitorowania i kontroli w zakresie telekomend oraz odbioru telemetrii. Misje satelitarne wymagają wyznaczonego personelu do prowadzenia w czasie rzeczywistym, w sposób ciągły, monitorowania stanu i położenia satelity. Kontrola misji obejmuje zestaw zadań wykonywanych po wyniesieniu na orbitę przez inżynierów operacyjnych przy pomocy aplikacji programowych i wiąże się z wymianą danych między segmentem naziemnym a kosmicznym w celu monitorowania i kontrolowania stanu podsystemów pokładowych satelity. W misjach naukowych konieczne jest również odbieranie informacji z ładunku użytecznego satelity, a zadania wykonywane w ramach kontroli misji obejmują odbiór i analizę telemetrii, telekomendowanie oraz śledzenie. Telemetria to dane transmitowane z deliver it to the end-users (scientific community). Typical functions exsatelity na Ziemię, informujące o stanie i warunkach pracy satelity oraz jego podsystemów. Telekomendy to polecenia przesyłane z Ziemi do statku kosmicznego w celu jego konfiguracji i obsługi. (Uhlig, Sellmaier i Schmidhuber 2015: 232). Śledzenie i utrzymywanie pozycji, znane również jako pomiar odległości, polega na monitorowaniu i określaniu trajektorii lotu oraz pozycji przy użyciu technik i sygnałów RF. Z perspektywy inżynierii oprogramowania sterowanie satelitą wymaga różnych aplikacji i narzędzi do analizy dynamiki lotu, planowania misji, telemetrii i wysyłania telekomend, sterowania siecią i routingu, a także interfejsów między nimi. Ta złożoność doprowadziła do opracowania różnych rozwiązań przez agencje kosmiczne. Jednym z najważniejszych kamieni milowych w rozwoju oprogramowania MCS była decyzja departamentu ESA ds. inżynierii systemów naziemnych o opracowaniu i udostępnieniu na licencji europejskiemu przemysłowi zestawu aplikacji programowych rozpowszechnianych pod nazwą MICONYS® 4 Satelity GEO są rozmieszczone na ograniczonym obszarze w przestrzeni. Pozycje orbitalne są przydzielane przez Międzynarodowy Związek Telekomunikacyjny (ITu) w celu uniknięcia kolizji — ryzyka związanego z problematyką śmieci kosmicznych, której poświęca się dziś coraz większą uwagę. 189Terminologia | 2020 | 27 (Mission Control System). MICONYS i jego komponent SCOS-2000® są prawdopodobnie najbardziej znanymi przykładami polityki ESA w zakresie rozwoju oprogramowania oraz transferu innowacji i technologii (Kaufeler, Jones and Karl 2001). SCOS-2000 obsługuje wysyłanie telekomend, odbiór telemetrii, wyświetlanie i archiwizację. SCOS-2000 był wynikiem doświadczeń zdobytych przez ESA podczas opracowywania i eksploatacji wcześniejszych podobnych systemów: MSSS, SCOS-1 i SCOS-2. Obecnie ESA opracowuje nowy system MCS, którego celem jest zastąpienie w przyszłości SCOS-2000. Jego nazwa to European Ground Systems – Common Core (EGS-CC). Podobnie jak SCOS, projekt ma na celu opracowanie wspólnej infrastruktury wspierającej monitorowanie i kontrolę misji kosmicznych w fazach przed startem i po starcie, z wykorzystaniem nowoczesnych technologii i architektur zorientowanych na usługi (Pecchioli et al. 2012). Opracowanie EGS-CC nie leży wyłącznie w zakresie odpowiedzialności ESA: europejskie krajowe agencje kosmiczne (CNES, UK Space Agency i DLR) oraz przedsiębiorstwa przemysłowe (AIRBUS Defence and Space, Thales Alenia Space i OHB Systems) są częścią projektu. Oprócz projektów ESA istnieją także inne inicjatywy mające na celu opracowanie generycznego systemu oprogramowania MCS. NASA zrealizowała podobne projekty, z których większość opracowano wewnętrznie. Centrum Lotów Kosmicznych Goddarda opracowało dwa systemy, ITOS i ASIST, do zarządzania misjami takimi jak WMAP (Wilkinson Microware Anisotropy Probe), IMAGE (Imager for Magnetopauseto-Aurora Global Exploration), EO-1 (Earth Observing 1), ST-5 (Space Technology 5), SdO (Solar Dynamics Observatory) czy LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). We wszystkich tych przypadkach mamy do czynienia ze złożonym systemem, który musi implementować różne funkcje, możliwe do aktywowania lub nie, w zależności od satelity i charakterystyki misji. w związku z tym te systemy intensywnie wykorzystujące oprogramowanie są dobrymi kandydatami do opracowania z zastosowaniem linii produktowych i technik modelowania opartego na cechach, które opierają się na jasnej i dobrze zorganizowanej organizacji pojęć w celu zrozumienia dziedziny i wymaganych możliwości systemu. 2. MODELOWANIE OPARTE NA CECHACH JAKO ORGANIZACJA POJĘĆ Modelowanie oparte na cechach jest jedną z technik stosowanych w inżynierii linii produktów programistycznych, dziedzinie zajmującej się tworzeniem wielokrotnego użytku programów, która zyskała popularność pod koniec lat dziewięćdziesiątych. SPLE ma na celu tworzenie wielokrotnego użytku 190 Ricardo Eito Brun Terminologia jako podstawa budowania Engineering Feature-based Models komponentów i artefaktów, które można następnie łączyć w celu budowania produktów dostosowanych do potrzeb konkretnego klienta i kontekstu. Doświadczenia w zakresie SPLE są szeroko udokumentowane w literaturze zawodowej i akademickiej. Capilla (2013) uwzględnił kilka studiów przypadków, w których SPLE zastosowano z powodzeniem: operacyjne, krytyczne dla misji programy lotnicze firmy Boeing do funkcji awioniki i kokpitu, oprogramowanie firmy Bosch do sterowania silnikami w systemach benzynowych, oprogramowanie drukarek firmy Hewlett Packard, urządzenia firmy Toshiba do wytwarzania i przesyłu energii oraz oprogramowanie sterujące firmy General Motors do układów napędowych. Korzyści płynące z linii produktów programistycznych (SPL), według Apela i in. (2013: 9), obejmują dostosowywanie produktów programistycznych do konkretnych potrzeb klientów, obniżenie kosztów – ponieważ zbiór wielokrotnego użytku zasobów można łączyć na różne sposoby w celu tworzenia nowych produktów –, poprawę jakości oraz skrócenie czasu wprowadzenia produktu na rynek. Cechy i modelowanie oparte na cechach są istotnymi pojęciami w rozwoju SPL. ISO/IEC/IEEE 24765:2010, Inżynieria systemów i oprogramowania — Słownik, zawiera ogólną definicję cech, zaczerpniętą z IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: „Wyróżniająca właściwość elementu systemu. UWAGA: obejmuje zarówno atrybuty funkcjonalne, jak i niefunkcjonalne, takie jak wydajność i możliwość ponownego użycia.” Kang i Lee (2013, 28) definiują cechy jako „abstrakcyjne pojęcia skutecznie wspierające komunikację między różnymi interesariuszami linii produktów, dlatego naturalne i intuicyjne jest wyrażanie przez ludzi wspólności i zmienności linii produktów w kategoriach cech.” Cechy służą różnym celom w procesie tworzenia koncepcji produktu i jego rozwoju. Są środkami komunikowania charakterystyki produktu oraz wspierają identyfikację wymagań; są one również koncepcjami, które kierują decyzjami dotyczącymi projektowania i implementacji. Opracowanie linii produktów obejmuje dwa uzupełniające się cykle życia: • inżynierię dziedzinową oraz • inżynierię aplikacji. Norma IEEE 1517-2010 definiuje inżynierię dziedzinową jako: „Cykl życia składający się z zestawu procesów służących określaniu i zarządzaniu wspólnością oraz zmiennością linii produktów. inżynieria dziedzinowa analizuje dziedzinę linii produktów i opracowuje zestaw artefaktów wielokrotnego użytku. Artefakty te obejmują wymagania dotyczące oprogramowania, elementy projektu, przypadki testowe oraz 191Terminologija | 2020 | 27 rodzaj inżynierii wymagań dla całej linii procedures, user documentation, etc. domain analysis can be seen as a produktów, obejmującej identyfikację przewidywanej zmienności. Główny artefakt generowany w ramach linii produktów. by domain analysis is the feature model that will specify and describe the Modelowanie cech jest techniką diagramowania wprowadzoną w latach dziewięćdziesiątych wraz z metodologią FOdA (Feature-Oriented Domain Analysis). FOdA dostarczała prymitywów do przedstawiania relacji strukturalnych (kompozycji, generalizacji i specjalizacji), opcjonalności, alternatywności oraz wzajemnych zależności. Później została poddana przeglądowi przez różnych autorów (Kang i Lee 2013: 30–31). Diagramy cech są wizualną reprezentacją modeli cech, w których cechy przedstawia się jako pola w hierarchicznym drzewie. Każdy węzeł ma dołączoną etykietę zawierającą nazwę cechy. Hierarchiczne rozmieszczenie cech tworzy relacje rodzic–dziecko. Jeśli wybrana zostanie cecha potomna, należy również wybrać jej cechę nadrzędną. diagramy mogą rozróżniać cechy obowiązkowe i opcjonalne oraz identyfikować kombinacje cech, które są prawidłowe. W szczególności diagramy cech mogą przedstawiać: • Cechy abstrakcyjne, które służą do organizowania cech w drzewie, ale nie są powiązane z artefaktami implementacyjnymi. Są one przedstawiane za pomocą szarych pól. • Cechy konkretne, które odpowiadają artefaktom implementacyjnym i są przedstawiane za pomocą białych pól. • Cechy obowiązkowe, które mają wypełnioną kropkę nad górną krawędzią swojego pola. • Cechy opcjonalne, które mają niewypełnioną kropkę nad górną krawędzią swojego pola. • Konieczność wybrania tylko jednej z cech potomnych określonego rodzica (alternatywa wykluczająca, XOR lub wybór jednej z wielu). Jest reprezentowana za pomocą pustego łuku przy dolnej krawędzi pola cechy nadrzędnej. • Możliwość wyboru więcej niż jednej cechy potomnej określonej cechy nadrzędnej (OR lub some-out-of-many). Jest reprezentowana za pomocą wypełnionego łuku przy dolnej krawędzi pola cechy nadrzędnej. • zależności między cechami, reprezentowane za pomocą strzałek z adnotacjami tekstowymi. 192 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Poniższy diagram przedstawia typowy diagram cech zgodny z opisanymi powyżej konwencjami: Rys. 1. Przykład diagramu cech (źródło: Gargantini 2015) Model cech powinien zawierać informacje dodatkowe względem diagramu. Apel i in. (2013: 27) wskazują na możliwość dodania następujących danych: • „Opis cechy i odpowiadającego jej zestawu wymagań. • Relacja z innymi cechami, zwłaszcza hierarchia, kolejność i grupowanie. • Zależności zewnętrzne, takie jak wymagane zasoby sprzętowe. • Zainteresowane strony. • Szacunkowy lub zmierzony koszt realizacji cechy. • Itp.” Opracowanie modelu cech reprezentującego funkcjonalną charakterystykę aplikacji programowych do sterowania satelitami musi rozpocząć się od jasnego zrozumienia i modelowania pojęć składających się na tę dziedzinę. W tym celu działania związane z terminologią i terminografią, identyfikacja terminów, pojęć oraz relacji między nimi stanowią podstawę do zbudowania modelu docelowego. 193Terminologija | 2020 | 27 3. METODOLOGIA PRACY Proponowany model cech został opracowany zgodnie z następującymi etapami: • Identyfikacja i przegląd literatury branżowej i akademickiej opublikowanej w tym obszarze. Obejmuje to wyszukiwanie informacji na temat podejścia stosowanego w projektach kosmicznych prowadzonych przez podmioty takie jak ESA (Europejska Agencja Kosmiczna) lub NASA (Narodowa Agencja Aeronautyki i Przestrzeni Kosmicznej). • opracowanie glosariusza na podstawie analizowanej literatury z zastosowaniem technik zarządzania terminologią w celu rejestrowania informacji o terminach, relacjach między nimi, definicjach zidentyfikowanych w dokumentach oraz kontekście, w którym terminy są używane. • Utworzenie modelu opartego na cechach, który przedstawia funkcje oferowane przez aplikacje programowe do monitorowania i kontroli satelitów, z wykorzystaniem glosariusza jako podstawy. Dane wejściowe wykorzystane do identyfikacji terminów obejmowały podzbiór dokumentów technicznych opisujących wybrany produkt: instrukcje obsługi, opracowania typu white paper oraz materiały szkoleniowe. Model cech jest hierarchicznym drzewem cech oznaczonych jako obowiązkowe lub the case of the software application under analysis, besides the identificaopcjonalne, z zależnościami między nimi. Oprócz cech opcjonalnych i obowiązkowych zidentyfikowano dodatkowe wymagania dotyczące zmienności linii produktów. W szczególności niektóre funkcje obsługiwane przez analizowane oprogramowanie wymagają nadpisania lub dostosowania istniejącego kodu. Identyfikację tych przypadków zmienności przeprowadzono przy wsparciu ekspertów zajmujących się tworzeniem i dostosowywaniem tego typu aplikacji. W celu zebrania tych informacji przeprowadzono wywiady indywidualne. Narzędziem wybranym do utworzenia modelu cech i diagramów jest FeatureIDE5. Jest to narzędzie open source oparte na języku Java i platformie Eclipse, opracowane przez pracowników Uniwersytetu Ottona i Fryderyka w Magdeburgu. Za pomocą FeatureIDE można utworzyć model cech przy użyciu edytora graficznego, oznaczyć cechy jako obowiązkowe, opcjonalne lub abstrakcyjne oraz zbudować hierarchiczne drzewo. Po zbudowaniu modelu cech można utworzyć różne konfiguracje: wybory cech, które zostaną wykorzystane do wygenerowania docelowego kodu źródłowego aplikacji5 Zob. https://FeatureIdE.github.io/. Ostatnia weryfikacja: 01-03-2018. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models kodu źródłowego. niestety narzędzie nie oferuje możliwości zarządzania terminami ani jednostkami terminologicznymi, co sprawia, że konieczne jest użycie narzędzi uzupełniających. Rys. 2. FeatureIDE (utworzony przez autora) 4. PREZENTACJA WYNIKÓW I DYSKUSJE Niniejsza sekcja podsumowuje jedną z sekcji modelu cech aplikacji oprogramowania systemów kontroli misji (MCS). Analiza koncepcji wyodrębnionych z dokumentów doprowadziła do uporządkowania funkcjonalności systemu w następujących obszarach: • Zarządzanie pulpitem i sesją, które zapewnia funkcje logowania, rozpoczynania sesji oraz uruchamiania różnych aplikacji. W przypadku zarządzania wieloma satelitami użytkownik będzie mógł przełączać się między obszarami roboczymi satelitów. • Łańcuch telemetryczny, który obejmuje przetwarzanie telemetrii, menedżera alarmów oraz wyświetlanie telemetrii.