I N Ż Y N I E R I A R U C H U M O R S K I E G O 2 00 5
ZESZYTY NAUKOWE NR 6(78)
AKADEMII MORSKIEJ
W SZCZECINIELucjan Gucma
Zastosowanie języka UML do budowy
środowiska symulacyjnego manewrowania i ruchu statków
na potrzeby systemu pilotowego
Przedstawiono poszczególne fazy budowy dużego projektu informatycznego – środowiska symulacyjnego przeznaczonego do badań manewrowania i ruchu stat-ków na potrzeby systemu pilotowego. Szczególną uwagę zwrócono na nowoczesne metody projektowania obiektowego z wykorzystaniem ujednoliconego języka mo-delowania UML (Unified Modeling Language), który jest światowym standardem służącym do właściwej organizacji procesu projektowania obiektowo zorientowa-nego oprogramowania.
Application of the UML in a Maneuvering Environment
Simulation Model for the Pilot Navigational System (PNS)
The paper presents different phases of largeIT project creation – the simula-tion environment of movement and maneuvering of ships for the needs of pilot nav-igation systems (PNS). The particular effort was placed on new methods of object modeling with the use of UML (Unified Modeling Language), which is a standard used for proper management of the object programming development process.
Złożone projekty informatyczne wymagają szczególnej koncentracji w fazie projektowania. Duże znaczenie mają rozwijane ostatnio techniki obiektowe, bez których niemożliwa jest realizacja większych i bardziej zaawansowanych pro-jektów, głównie modeli symulacyjnych kompleksowych systemów rzeczywi-stych.
Budowa środowiska symulacyjnego przeznaczonego do badań manewro-wania i ruchu statków też wymaga znacznej koncentracji w fazie projektomanewro-wania systemu. Bardzo istotne jest, aby wszyscy zaangażowani w projekcie analitycy, programiści i odbiorcy oprogramowania mogli posługiwać się jednolitym języ-kiem i rozumieć się nawzajem podczas budowy modelu. W tym celu stworzono ujednolicony język modelowania, który jest utrzymywany i standaryzowany przez szereg dużych firm zajmujących się oprogramowaniem (HP, DEC, Oracle, Microsoft, IBM itp.), należących do organizacji OMG (Object Management
Group). Pierwsza wersja standardu UML 1.0 powstała w 1997 roku, a obecnie
dostępna jest wersja 2.0 z 2004 roku. W dużej mierze UML jest językiem gra-ficznym składającym się z diagramów. Jego zastosowanie jest analogiczne do rysunku technicznego w budownictwie – każdy z uczestników projektu może od-czytać go pod warunkiem znajomości jego zapisu.
1. Elementy języka UML
Język UML umożliwia wspomaganie modelowania obiektowego za pomo-cą standaryzowanego języka graficznego w postaci diagramów [6]. W termino-logii modelowania matematycznego model taki można sklasyfikować jako mo-del logiczny, umożliwiający uwzględnianie dynamicznych zmian w projektowa-nym systemie. Elementy modelowania obiektowego za pomocą języka UML możemy podzielić na statyczne i dynamiczne. Do podstawowych elementów ję-zyka UML mających zastosowanie w budowaniu środowiska symulacyjnego manewrowania i ruchu statku można zaliczyć:
1) diagramy klas, 2) diagramy obiektów,
3) diagramy przypadków użycia, 4) diagramy stanów,
5) diagramy przebiegu, 6) diagramy czynności, 7) diagramy kooperacji, 8) i inne.
Pierwsze dwa mają charakter statyczny. Diagram klas przedstawia klasy modelu, a więc pewne kategorie modelowanej rzeczywistości razem z ich ce-chami (atrybutami) oraz czynnościami (działaniami). Przykładowo klasy typu klasyczne stery okrętowe mogą mieć takie atrybuty jak: powierzchnia,
wyso-kość, typ. Przykładowymi czynnościami sterów mogą być „oblicz siłę na ste-rze”, „zmień kąt steru” itp. Bardzo istotnym elementem jest określenie powiązań i zależności pomiędzy klasami.
Diagram obiektów przedstawia instancje klas – obiekty powstałe podczas działania programu. Przykładowo, statek może posiadać dwa obiekty typu śruba, które należą do wspólnej klasy śrub okrętowych.
Diagram przypadków użycia służy przede wszystkim do określania stopnia interakcji użytkownika z oprogramowaniem, a więc możliwych czynności, jakie może wykonać za jego pomocą. Służy on również do zabezpieczania się przed nietypowym zachowaniem się użytkownika.
Diagram stanów przedstawia stany, w jakich może znajdować się dany obiekt i przejścia pomiędzy kolejnymi stanami. Przykładowo, autopilot może być wyłączony, włączony i ustawiony na zadanym kursie bądź zadanej trasie. Może być również uszkodzony. Przejścia pomiędzy stanami odbywają się na żą-danie użytkownika, po zadanym czasie lub losowo.
Diagram przebiegu pokazuje oddziaływania pomiędzy obiektami w czasie i ich wpływ na siebie. Za jego pomocą można modelować na przykład sekwen-cje tworzenia i usuwania obiektów podczas działania programu.
Diagram czynności przedstawia działanie obiektów w czasie bez określania interakcji pomiędzy nimi. Jest to popularny schemat blokowy systemu z drze-wami decyzyjnymi.
Diagram kooperacji ma za zadanie określanie współdziałania obiektów po-między sobą w celu zrealizowania założonego zadania.
2. Model symulacyjny ruchu statku – wstępna analiza obiektowa
Głównymi założeniami środowiska symulacyjnego ruchu i manewrowania statków, poza typowymi wymaganiami w stosunku do tego rodzaju modeli były możliwości:
dynamicznego tworzenia i usuwania różnych modeli statków w syste-mie;
modelowania statków posiadających różny napęd i urządzenia sterowe; modelowania różnych urządzeń kontrolnych na statkach w zależności od
typu urządzeń sterowniczych i napędu; zmiany statku własnego podczas symulacji;
zmiany parametrów dynamicznych statków podczas symulacji; przyspieszania czasu symulacji;
budowy wielu paneli sterowniczych na jednym komputerze – sterowanie wieloma statkami równocześnie;
modelowania interakcji pomiędzy statkami;
dowolnej, dynamicznej zmiany warunków zewnętrznych podczas symu-lacji;
interaktywnej pracy w sieci i wizualizacji innych statków modelowa-nych na inmodelowa-nych stanowiskach symulacyjmodelowa-nych.
Spełnianie powyższych wymagań jest praktycznie niemożliwe bez zasto-sowania technik programowania obiektowego. W literaturze dotyczącej mode-lowania symulacyjnego ruchu statków możliwość wykorzystania technik obiek-towych przedstawiono już w 1992 roku [1]. Baker zaprezentował ogólną kon-cepcję i możliwości budowy modeli symulacyjnych ruchu statku z wykorzysta-niem technik obiektowych. Bardziej interesująca jest propozycja przedstawiona w pracy [5], bo podaje szczegółowe rozwiązania modelowania obiektowego na potrzeby modeli symulacyjnych ruchu statków.
Model hydrodynamiczny wykorzystany w niniejszym środowisku symula-cyjnym był wielokrotnie omawiany [4]. Jest on ciągle udoskonalany przez ze-spół badawczy inżynierii ruchu morskiego AM w Szczecinie, a jego podstawo-wymi zaletami jest uniwersalność, możliwość szybkiej rozbudowy i bazowanie na uogólnionych wynikach eksperymentalnych. Dzięki tym cechom eliminuje się konieczność każdorazowej identyfikacji modelu. Identyfikacja taka jest nie-możliwa w większości praktycznych zadań inżynierii ruchu morskiego. Wadą modelu są uproszczenia i liniowy opis ruchu wzdłużnego statku. Schemat mode-lu komputerowego ruchu statku przedstawiono na rys. 1.
Rys. 1. Schemat modelu symulacyjnego ruchu statku
Sternik/Operator
Nawigator Zobrazowanie mapy elektronicznej Zobrazowanie 3D
Zobrazowanie urządzeń sterowniczych
Baza danych warunków hydrometeorologicznych Wizualizacja Model symulacyjny Moduł obliczania przyspieszeń (hydrodynamika) Moduł obliczania sił Moduł aktualizacji współrzędnych stanu Baza danych nawigacyjno-hydrograficznych
W stosowanej nomenklaturze modeli hydrodynamicznych statków [3] model ta-ki można sklasyfikować jako model siłowy (ruch statku wywoływany jest siłami pochodzącymi z różnych oddziaływań) o budowie modułowej. Zastosowana technika hermetyzacji daje dodatkowe możliwości rozszerzania modelu i wpro-wadzaniu do niego szybkich zmian.
3. Realizacja projektu
Po określaniu wstępnych wymagań do środowiska symulacyjnego przystą-piono do budowy podstawowej struktury klas modelu. Wykorzystano do tego diagram klas. Na rysunku 3 przedstawiono wstępny diagram klas modelu. Za-znaczono na nim zależności typu agregacja (posiadanie) wraz z zakładaną li-czebnością tych powiązań. Ograniczenia liczebności mają charakter związany przede wszystkim ze standardowym formatem danych opisujących statek oraz z urządzeniami do sterowania urządzeniami statkowymi. Widać również, że tworzone obiekty śruba czy ster będą własnością tylko jednego statku, a statek będzie mógł posiadać od zera do 3 sterów strumieniowych. W większości przy-padków urządzeń statkowych będą to agregacje całkowite (ciemny romb) infor-mujące, że dany komponent (ster, śruba) składa się na większą całość, jaką w tym przypadku jest statek. Zależności pomiędzy poszczególnymi obiektami i klasami zaznaczono za pomocą strzałek. Należy zauważyć, że klasa TSwiat może zawierać dowolną liczbę statków. Jest ona odpowiedzialna za przepływ in-formacji w modelu, wymianę inin-formacji z graficznym interfejsem użytkownika i zarządzanie statkami.
Rys. 3. Wstępny diagram klas modelu (agregacje)
Dziedziczenie to technika pozwalająca na dokładniejsze modelowanie rze-czywistości oraz znaczną oszczędność i przejrzystość tworzonego kodu
progra-mu. Dzieje się tak dlatego, że dziedziczące klasy lub obiekty mogą korzystać z metod (funkcji) i atrybutów klas nadrzędnych. Przykładowy wstępny diagram klas z hierarchią dziedziczenia urządzeń sterowo-napędowych przedstawiono na rys. 4. Klasy abstrakcyjne, nie posiadające własnych atrybutów, a jedynie meto-dy zaznaczono drukiem pochyłym.
Rys. 4. Wstępny diagram klas urządzeń napędowo-sterowych (dziedziczenie)
Ostateczny widok diagramu klas modelu pokazano na rys 5. Diagram klas pozwala prześledzić statyczne związki pomiędzy klasami i powstającymi na ich podstawie obiektami takimi jak: zależność, agregacja czy uogólnianie (dziedzi-czenie).
Podczas działania modelu powstaje i niszczonych jest wiele obiektów. Aby prześledzić dynamiczne zachowanie się modelu stosuje się diagramy przebiegu. W diagramie tym na osi czasu X pokazane są zdarzenia i stany obiektów mode-lu. W prezentowanym przypadku (rys. 6.) jest to sekwencja powstawania skła-dowych obiektów (komponentów) w obiekcie statek.
Diagram kooperacji służy przede wszystkim do pokazania, jakie informacje będą ze sobą wymieniać obiekty. Rysunek 7 prezentuje diagram kooperacji z in-terfejsem, który ma za zadanie określić interakcje użytkownika z obiektami two-rzonego modelu i komunikaty przesyłane do nich.
L u cjan Gu cm a 92 Ry s. 5 . Os tate cz n y d ia g ra m k las z za zn ac zo ny m i z wią zk am i p om ięd zy k la sa m i
Rys. 6. Diagram przebiegu (sekwencja tworzenia obiektów)
Diagram czynności jest podobny do schematu blokowego. Przedstawia ko-lejne kroki oraz punkty podejmowania decyzji i rozgałęzienia. W sposób przej-rzysty można obserwować jak wygląda przepływ sterowania w modelowanym obiekcie. Przykładowy diagram czynności dla obiektu TStatek zaprezentowano na rys. 8.
Model zrealizowano jako dynamicznie ładowaną bibliotekę DLL. Umożli-wia to całkowite oddzielenie jej od systemu pilotowego, który oferował interfejs mapy elektronicznej. Biblioteka posiada własne formularze do wyświetlania pulpitu sterowniczego statku. Schemat takiej realizacji przedstawiono na rys. 9.
Rys. 9. Praktyczna realizacja modelu jako biblioteki dołączonej do systemu pilotowego
Istnieje duży wybór oprogramowania pozwalającego na projektowanie sys-temów za pomocą języka UML (np. Poseidon). Oferują one często automatycz-ne przekształcenie zbudowaautomatycz-nego modelu logiczautomatycz-nego w zrozumiały przez kompi-lator kod źródłowy. W niniejszym przypadku praktyczną implementację wyko-nano za pomocą oprogramowania ModelMaker współdziałającego z kompilato-rem Delphi. Wprawdzie aplikacja ta umożliwia automatyczne wygenerowania kodu w Object Pascal, to wyniki nie zawsze są zgodne z oczekiwaniami, szcze-gólnie jeśli chodzi o czytelność kodu.
Do praktycznej implementacji modelu zastosowano kompilator Delphi 7 pozwalający na budowę efektywnego kodu obiektowego w języku Object
Pas-cal. Kod środowiska symulacyjnego w obecnej fazie ma ponad 5000 linii (bez
wizualizacji), a więc należy do dużych przedsięwzięć informatycznych. Na ry-sunku 10 zamieszczono widok interfejsu systemu pilotowego z symulowanymi wieloma statkami.
Do zmiany parametrów statków i zmiany statku własnego na obcy i od-wrotnie zastosowano formularz (okno) generowany bezpośrednio z poziomu bi-blioteki DLL. Pozwala on również na zmianę stanu obiektów oraz wirtualne przechodzenie pomiędzy statkami. Statki obce w zależności od ustawień pro-gramu sterowane są autopilotem, lub realizują zadaną sekwencję nastaw w czasie. Interesująca jest również możliwość prezentacji przeszłej pozycji statku (predykcji). Jest ona bardzo istotnym elementem systemów pilotowych. Pierw-sze badania nad systemami predykcji prowadził autor w ramach rozprawy dok-torskiej [2]. Tak zbudowany system pozwala na bardzo łatwe przedstawienie przyszłych pozycji statku, obliczonej za pomocą dokładnego modelu hydrody-namicznego, ekstrapolacji bądź najbardziej zaawansowanych technik adaptacyj-nych polegających na adaptacji i uczeniu się dynamiczadaptacyj-nych właściwości statku w czasie.
Rys. 10. Przykładowy interfejs systemu pilotowego z wieloma statkami na podejściu do Świnoujścia wygenerowanymi za pomocą zbudowanego modelu symulacyjnego
Rys. 12. Prezentacja przyszłej pozycji statku (system predykcji, odstępy 1 min)
Wnioski
Stosowanie technik obiektowych jest obecnie standardem, a w wielu dzie-dzinach takich jak modelowanie systemów rzeczywistych po prostu konieczno-ścią. Do wspomagania projektowania obiektowego stosuje się standardowy ję-zyk graficzny UML. W artykule przedstawiono kolejne fazy budowy projektu modelu symulacyjnego ruchu statków za pomocą języka UML na potrzeby sys-temu pilotowego. Analiza obiektowa pozwoliła zbudować odporny na błędy zrozumiały oraz podatny na zmiany program symulacyjny ruchu statków. Model taki zastosowano w praktyce podczas badania systemów pilotowych. Ze wzglę-du na zdefiniowanie interfejsów wymiany danych pomiędzy obiektami możliwa jest bardzo szybka wymiana i udoskonalanie poszczególnych modułów modelu.
Literatura
1. Baker M.A., Applying Object-Oriented Programming Techniques to Ship
Modeling. Maneuvering and Control of Marine Craft (Wilson P.A. edt.)
CMP. Southampton 1992.
2. Gucma L. Predykcja w systemie map elektronicznych jako czynnik
bezpie-czeństwa manewru. Rozprawa doktorska. WSM Szczecin 1999.
3. Gucma L. Modelowanie ilościowych czynników ryzyka zderzenia statków
4. Gucma S. Metody wyznaczania i kształtowania dróg wodnych. WSM Szcze-cin 1990.
5. Han-Jin Lee i inni. Development of shiphandling simulator by object oriented
software design. Proc. of Marsim Conference. Orlando 2000.
6. Rumbaugh J., Jacobson I, Booch G. The Unified Modeling Language
Refer-ence Manual. Addison-Wesley 1999.
Recenzenci
dr hab. inż. Cezary Szpecht, prof. AMW prof. dr hab. inż. Bolesław Mazurkiewicz
Adres Autora
dr inż. Lucjan Gucma
Akademia Morska w Szczecinie Instytut Inżynierii Ruchu Morskiego ul. Wały Chrobrego 1/2
70-500 Szczecin lucek@am.szczecin.pl
