Generator dokumentacji dla kodów źródłowych środowiska Matlab

Transkrypt

1 ograniczone do obszaru konwertera i doprowadzenia wiązki do pacjenta, izocentryczne ramię gantry posiada wymiar ok. 2 m i wagę 12 t. EuCARD Europejskie akceleratorowe środowisko naukowe przygotowuje zgłoszenie projektu infrastrukturalnego do programu ramowego FP8. Badania podstawowe w dziedzinie akceleratorów RF obejmują zwiększenie jasności i energii oraz mocy wiązki, a także zagadnienia polaryzacji wiązki. Dla wiązek elektronowych istotne jest zmniejszenie emitancji w synchrotronowych źródłach światła, pierścieniach akumulacyjnych, pierścieniach dławiących, deceleratorach, zderzaczach leptonowych. Optymalizacja energetyczna akceleratorów dotyczy ich zrównoważonego i energetycznie wydajnego rozwoju. Te badania nad odzyskiwaniem energii z wiązki po eksperymencie, nad efektywnymi metodami akceleracji mają zapobiec exponencjalnemu wzrostowi zapotrzebowania akceleratorów na energię. Badania nad nowymi rozwiązaniami technicznymi dotyczą konstrukcji maszyn hadronowych (silne magnesy, źródła hadronów, kolimatory, wigglery, undulatory), maszyn SRF i NRF oraz akceleratorów laserowo-plazmowych. Badania nad akceleratorami plazmowymi mają doprowadzić w Europie do budowy działającej infrastruktury nadawczej w tym obszarze. Badania nad zastosowaniami akceleratorów mają doprowadzić do ich znacznie szerszych zastosowań w przemyśle, ochronie zdrowia, produkcji energii i bezpieczeństwie. Literatura [1] py?confid= [2] Tajima T.: ELI Courier 2 (3), pp. 4 5 (2010). [3] Czarski T., et al.: NIMA 548 (3), pp (2005). [4] Czarski T., et al.: NIMA 568 (2), pp (2006). [5] Czarski T., et al.: NIMA 556 (2), pp (2006). [6] Ackerman W.: Nature Photonics 1 (6), pp (2007). [7] Chatrchyan S., et al.: JINST 3 (8), art.s08004 (2008). [8] Chatrchyan S., et al.: JINST 5 (3), art.t03001 (2010). [9] Chatrchyan S., et al.: JINST 5 (3), art.t03002 (2010). [10] Chatrchyan S., et al.: JINST 5 (3), art.t03003 (2010). [11] Chatrchyan S., et al.: JINST 5 (3), art.t03004 (2010). [12] Chatrchyan S., et al.: JINST 5 (3), art.t03005 (2010). [13] Chatrchyan S., et al.: JINST 5 (3), art.t03006 (2010). [14] Chatrchyan S., et al.: JINST 5 (3), art.t03007 (2010). [15] Chatrchyan S., et al.: JINST 5 (3), art.t03008 (2010). [16] Chatrchyan S., et al.: JINST 5 (3), art.t03009 (2010). [17] Chatrchyan S., et al.: JINST 5 (3), art.t03010 (2010). [18] Chatrchyan S., et al.: JINST 5 (3), art.p03007 (2010). [19] Chatrchyan S., et al.: JINST 5 (3), art.t03011 (2010). [20] Chatrchyan S., et al.: JINST 5 (3), art.t03012 (2010). [21] Chatrchyan S., et al.: JINST 5 (3), art.t03013 (2010). [22] Chatrchyan S., et al.: JINST 5 (3), art.t03014 (2010). [23] Chatrchyan S., et al.: JINST 5 (3), art.t03015 (2010). [24] Chatrchyan S., et al.: JINST 5 (3), art.t03016 (2010). [25] Chatrchyan S., et al.: JINST 5 (3), art.t03017 (2010). [26] Chatrchyan S., et al.: JINST 5 (3), art.t03018 (2010). [27] Chatrchyan S., et al.: JINST 5 (3), art.t03019 (2010). [28] Chatrchyan S., et al.: JINST 5 (3), art.t03020 (2010). [29] Chatrchyan S., et al.: JINST 5 (3), art.t03021(2010). [30] Chatrchyan S., et al.: JINST 5 (3), art.t03022 (2010). [31] Romaniuk R., et al.: MST, vol.18, no.8, art. E01 (2008). [32] Fąfara P., et al.: MST, vol.18, no.8, pp (2008). [33] Burd A., et al.: New Astronomy 10 (5), pp (2005). [34] Burd A., et al.: Astronomische Nachrichten 325 (6-8), pp. 674 (2004). [35] Burd A., et al.: Proc. SPIE 6159, art H (2006). [36] Stankiewicz S., et al.: IEEE Nuclear Science Symp. Conf.Rec.,vol.1, pp (2004). [37] Mukherjee B. et al.: Radiation Protection Dosimetry 126 (1 4), pp (2007). [38] Romaniuk R.: Phot.Lett.Poland 1 (1), pp. 1 3 (2009). [39] Romaniuk R.: Phot.Lett.Poland, 1 (2), pp (2009). [40] Kasprowicz G., et al.: Phot.Lett.Poland 1 (2), pp (2009). [41] Romaniuk R.: Phot.Lett.Poland 1 (3), pp (2009). [42] Romaniuk R.: Phot.Lett.Poland 2 (1), pp (2010). [43] Romaniuk R.: Phot.Lett.Poland 2 (2), pp (2010). [44] Romaniuk R.: Phot.Lett.Poland 2 (2), pp (2010). [45] Obroślak P., et al.: Phot.Lett.Poland 2 (3), pp (2010). [46] Romaniuk R.: Bulletin of PAS 56 (2), pp (2008). [47] Dorosz J., et al.: Optica Applicata 28 (4), pp (1998). [48] Dorosz J., et al.: Optica Applicata 28 (4), pp (1998). [49] Romaniu R., et al.: Optica Applicata 29 (1), pp (1999). [50] Romaniuk R.: Optica Applicata 31 (2), pp (2001). Generator dokumentacji dla kodów źródłowych środowiska Matlab inż. Bartłomiej Nitoń, dr inż. Krzysztof Poźniak, prof. dr hab. inż. Ryszard Romaniuk Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut Systemów Elektronicznych Dobrze udokumentowany kod źródłowy jest prostszy do dalszego wykorzystania, ponieważ zawiera uzupełniające informacje, których nie można zawrzeć bezpośrednio w danym języku programowania. Udokumentowanie pomaga m.in. w prawidłowym wykorzystaniu powstałych kodów oraz w realizacji większych projektów wykonywanych przez grupę programistów. Sprzyja także wykrywaniu błędów w projekcie. Ponadto dokumentacja zawarta w pliku źródłowym staje się jego nierozdzielną częścią. Dokumentowanie programów, choć niesie ze sobą liczne korzyści, stanowi zazwyczaj ostatni etap realizacji projektu, na którego wykonanie albo już nie wystarcza czasu, albo nie przywiązuje się do tego zadania dostatecznej wagi. Wynika to głównie z faktu, że dokumentowanie kodów źródłowych to żmudny i pracochłonny proces. Dlatego w celu jego automatyzacji powstały narzędzia nazwane generatorami dokumentacji dla kodów źródłowych. Generatory dokumentują pliki źródłowe na podstawie komentarzy umieszczonych w kodzie oraz struktury leksykalnej danego języka programowania. Zadaniem programisty jest jedynie zamieszczenie lub modyfikacja treści komentarza blisko wprowadzanego lub modyfikowanego kodu źródłowego. Generator automatycznie sformatuje ten komentarz w czytelną dla użytkownika 120 informację. Formatowanie informacji wyjściowej można generalnie podzielić na: interaktywne, do której m. in. można mieć dostęp poprzez sieć (np. format HTML), do druku, np. format Postscript, PDF, RTF itp., opisujące strukturę kodu, np. format XML. Najczęściej oferowanym przez generatory dokumentacji formatem wyjściowym, często jedynym, jest HTML [1 41]. Inną grupą wyróżniającą się w tym podziale są aplikacje generujące wiele formatów wyjściowych: Ddoc, ROBODoc, fpdoc oraz Doxygen [8, 14, 32, 40]. Współczesne generatory dokumentacji mogą generować wiele formatów wyjściowych w zależności od aktualnego zapotrzebowania użytkownika. Oferują także wiele właściwości dodatkowych, takich jak np. dostosowywanie elementów formatów wyjściowych do potrzeb użytkownika, wyodrębnianie słów kluczowych, a w szczególności generowanie grafów. [1 41]. Za pomocą grafów można przedstawić w sposób hermetyczny np. strukturę kodu, powiązania w nim występujące, kolejność wywoływania funkcji. Szczególnie użyteczna jest możliwość generacji grafów zgodnych ze standardem UML. Umożliwiają to takie aplikacje jak: Project Analyzer, Enterprise Architect oraz Imagix 4D [20, 30, 41]. Elektronika 12/2011

2 Obecnie dostępne generatory dokumentacji umożliwiają dokumentacje wielu różnych języków programowania [1 41]. Jednakże kompletną analizę kodów źródłowych języka Matlab zapewniają nieliczne programy komercyjne jak np. Doc-O-Matic, Universal Report oraz mechanizm dokumentacji wbudowany w środowisko Matlab [10, 34, 42]. Ostatni z wymienionych nie umożliwia jednak zgromadzenia wszystkich danych na temat kodu źródłowego w jednym pliku lub połączonej hiperłączami strukturze. Podsumowując, można stwierdzić, że obecnie nie jest dostępna aplikacja tworząca kompletną, darmową i odseparowaną od kodu źródłowego dokumentację dla środowiska Matlab. Z powyższych względów w niniejszym artykule przedstawiono autorski projekt generatora dokumentacji dla kodów źródłowych Matlab, generujący dodatkowo grafy klas zgodnie ze standardem UML. Dobór narzędzi przetwarzania kodów źródłowych Podstawowy schemat funkcjonalny generatora dokumentacji zobrazowano na rys. 1. Dobór narzędzi umożliwiających realizację projektu podzielono na trzy główne etapy: wybór bazowego generatora dokumentacji, uzupełnienie go o wsparcie dla środowiska Matlab oraz dodanie generatora grafów klas zgodnych ze standardem UML. Dokonano analizy darmowych generatorów dokumentacji pod względem dostępności ich kodów źródłowych, wsparcia dla języka Matlab, możliwości generacji grafów klas w standardzie UML oraz możliwości generacji rezultatów analizy w formacie HTML. Jako dodatkowe kryterium przyjęto czytelność i estetyczność generowanej dokumentacji. Wybrano dostępny na wolnej licencji GPL (ang. General Public License) program Doxygen [40]. Doxygen działa na większości platform bazujących na Unixie, Windowsie oraz w środowisku Mac OS X. Wspiera wiele języków programowania (C++, C, Java, Objective-C, Python, IDL, Fortran, VHDL, PHP, C#, częściowo D). Umożliwia generowanie różnych formatów wyjściowych (HTML, LaTeX, RTF, PostScript, hyperlinked PDF, compressed HTML, XML oraz Unix man pages). Doxygen stwarza możliwość generowania grafów zawołań, jak i wywołań funkcji, przynależności, a także diagramy dziedziczenia. Grafy mogą zostać utworzone przez wewnętrzną funkcję Doxygena, jak i z wykorzystaniem programu Graphviz. Rys. 2. Ogólny schemat komentowania plików matlabowych Fig. 2. General diagram of commenting of Matlab files udokumentowanych klas i funkcji. Natomiast do generowania grafów klas zgodnych ze standardem UML wykorzystano mechanizmy wbudowane w Doxygena. Na rysunku 2. przedstawiono ogólny schemat dodawania komentarzy do kodów źródłowych Matlaba, w formacie analogicznym jak dla pozostałych aplikacji generujących dokumentację dla kodów źródłowych, np.: JavaDoc, Doc-O-Matic czy Doxygen. Format bloku komentarza, to występujące po sobie linie komentarza rozpoczynające się od znaków %!. Blok komentarza kończy się wraz z pierwszą linią pliku nie rozpoczynającą się od znaków %!. Pierwsza linia bloku komentarza stanowi tzw. krótki opis elementu, pozostałe linie składają się na pełny opis elementu. Przed kodem źródłowym bloku classdef, funkcji lub skryptu może wystąpić dowolna liczba bloków komentarza. Kolejne bloki powinny być od siebie oddzielone przynajmniej jedną pustą linią. Każdy z nich opisywać będzie element zdefiniowany poprzez komy specjalne Doxygena lub zostanie zignorowany. Ostatni blok występujący przed kodem źródłowym domyślnie opisuje występującą za nim klasę (blok classdef), funkcję lub skrypt chyba, że poprzez komy specjalne zdefiniowano inaczej. Na rysunkach 3 5 przedstawiono sposoby komentowania elementów klasy dla Matlaba w wersji do 7.6 oraz wyższych. Zakładając, że na początku pliku źródłowego zawierającego definicję klasy (blok classdef) występuje tylko jeden blok komentarza, domyślnie zostanie on uznany za opis klasy. Każde wprowadzane pole klasy (w bloku properties) lub zdarzenie (blok events) można opisać pojedynczą linią komentarza (rozpoczynającego się od znaków %! ), będzie ona uznana za krótki opis pola lub zdarzenia klasy. Wprowadzane w bloku metod klasy (methods) funkcje można opisywać blokami komentarza zawierającymi zarówno pełny jak i krótki jej opis. Rys. 1. Schemat funkcjonalny generatora dokumentacji Fig. 1. Functional diagram of documentation generator Moduł do automatycznego dokumentowania języka Matlab Głównym celem omawianego projektu było autorskie rozwinięcie programu Doxygen o wsparcie dla języka Matlab w zakresie funkcjonalnym zbliżonym do obsługi innych języków programowania, m.in. dokumentowanie kodu źródłowego na podstawie komentarzy lub samej struktury kodu, generowanie dokumentacji funkcji globalnych oraz klas zarówno dla obecnej wersji programu Matlab jak i poniżej 7.6. Zdecydowano się na opracowanie modułu zintegrowanego z Doxygenem oraz parsera kodu Matlab za pomocą oprogramowania Bison i Flex [43, 44]. Doxygen umożliwia stosowania w blokach komentarza specjalnych kom i znaków mających bezpośredni wpływ na generowany format wyjściowy jak i prezentację informacji. Opracowany moduł umożliwia parsowanie komentarzy, co umożliwia interpretowanie kom i znaków specjalnych, kom XML, HTML oraz formuł LaTeXa. analogicznie jak dla pozostałych języków programowania wspieranych przez Doxygen. Program Doxygen może dołączać do dokumentacji przeredagowane kody źródłowe. Z tego powodu do modułu dodano dodatkowy analizator leksykalny na bazie programu Flex, który wyróżnia słowa kluczowe, łańcuchy znakowe, komentarze oraz dodaje linki do classdef classname properties PropName1 PropName2 methods Deklaracja lub definicja metody methodname1 Deklaracja lub definicja metody methodname2 events EventName1 EventName2 Rys. 3. Schemat komentowania klas dla Matlaba w wersji od 7.6 Fig. 3. Diagram of commenting of Matlab classes from ver.7.6. Elektronika 12/

3 function w=konstruktorklasy(varargin) w.nazwapola1 = 10; w.nazwapola2 = 1; w = class(w, wahadlo ); Rys. 4. Schemat komentowania klas dla Matlaba poniżej wersji 7.6 w przypadku wprowadzania jej pól poprzez przypisanie Fig. 4. Diagrame of commenting of classes for Matlab below ver. 7.6, in case of class introduction by assigning function tpl = konstruktorklasy(varargin) tpl = struct('nazwapola1','.'...,' nazwapola2',{{}}...,' nazwapola3','remove'); tpl = class(tpl,'template'); Rys. 5. Schemat komentowania klas dla Matlaba poniżej wersji 7.6 w przypadku wprowadzania jej pól poprzez zdefiniowanie struktury Fig. 5. Diagram of commenting of Matlab classes below ver.7.6 in the case of class fields introduction by structure definition Na rysunkach 4 i 5. przedstawiono sposób dokumentowania klas dla wersji Matlaba poniżej 7.6. Pola klasy są definiowane wewnątrz konstruktorów klasy jako struktura, a następnie inicjalizowane poprzez funkcję class. Na rysunku 5. przedstawiono sposób komentowania pól klasy w przypadku, kiedy są one dodawane przy definiowaniu struktury. Każde nowo dodane pole można opisać pojedynczą linią komentarza (rozpoczynającego się od znaków %! ) występującą za jego zdefiniowaniem w strukturze. Blok komentarza będzie stanowił opis konstruktora klasy. Wybrane przykłady zastosowania generatora dokumentacji Dokumentowanie klas dla Matlaba w wersji od 7.6 Omówiony przykład dokumentowania klasy dla Matlaba w wersji od 7.6 będzie zgodne ze schematami z rys. 2 i 3. Na rys. 6 przedstawiono strukturę katalogu przykładowej klasy wahadlo2 kod źródłowy jej definicji oraz dokumentację w formacie HTML: Po prawej stronie rys. 6 przedstawiono dokumentację klasy wahadlo2. Jest rozpoczęta krótkim opisem. Następnie zamieszczono opisy jednostek składowych klasy. Zostały one umieszczono w odpowiednich sekcjach: funkcji i atrybutów publicznych, chronionych lub prywatnych. Na opisy metod klasy w sekcji dokumentacji klasy Rys. 6. Przykładowa poprawnie skomentowana klasa wraz z jej strukturą katalogową (po lewej) oraz dokumentacja do niej w formacie HTML (po prawej) dla matlaba od wersji 7.6 Fig. 6. Example of properly commented class together with its catalogue structure (left window), and its documentation in the HTML format (Wright window), for Matlab in ver.7.6. and above 122 Elektronika 12/2011

4 Rys. 7. Przykładowe dokładne opisy elementów klasy wahadlo2 Fig. 7. Exemplary detailed descriptions of components for a claaa wahadlo2 składają się zwracane argumenty, nazwa, argumenty wywołania oraz krótki opis metody. Na końcu znajduje się pełny opis klasy (Detailed Description). W kolejnej sekcji znajdują się pełne dokumentacje elementów klasy, co pokazano na przykładzie na rys 7. Nazwy pól i metod klasy poprzedzone zostały znacznikiem zakresu klasy wahadlo2 (wahadlo2::). Dla pól i zdarzeń klasy zostały umieszczone krótkie opisy, po których następuje wskazanie linijki w pliku z definicją klasy. Linia definicji elementu jest także określona dla metod klasy. Metody klasy poza krótkim opisem zostały także opatrzone pełnym opisem pobranym z bloku komentarza metody. W wypadku, kiedy opisywany element posiada parametry, zostają one wymienione za nazwą elementu w nawiasach kwadratowych. Kliknięcie zaznaczonego na niebiesko tekstu List of all members. (por. prawą stronę rys. 6.) spowoduje przeniesienie widoku do strony HTML, w której zostały wymienione wszystkie (także dziedziczone) elementy klasy wahadło2. Struktura dokumentacji klasy w bloku classdef jest analogiczna jak dla wcześniejszych wersji matlaba. Posiada jednak wiele dodatkowych opcji, np. możliwość wykorzystania atrybutów do wskazania poziomu dostępu do elementów klasy. Poza poziomem dostępu do metod typu public i private możliwe jest określenie protected. Wtedy metody te zostaną dołączone do sekcji Protected Memeber Functions. Możliwe stało się także określanie poziomu dostępu do pól klasy (patrz sekcja Protected Atributes ). Na rysunku 6. przedstawiono wpływ atrybutu hidden i static na elementy klasy. Pierwszy z nich blokuje pojawienie się elementu w dokumentacji. Pomimo zadeklarowania w kodzie źródłowym pole property3 zostało pominięte w dokumentacji. Element statyczny static natomiast zostaje dołączony do listy elementów statycznych danego typu (patrz krótki opis funkcji obj() w sekcji Static Private Member Functions ). Podobnie oznaczane były elementy statyczne niebędące funkcjami. Na rysunku 6. przedstawiono także sposób dołączania pól klasy będącej zdarzeniami. Zostają one umieszczone wraz ze swoimi krótkimi opisami w sekcji Events. Natomiast elementy nieskomentowane są dołączane do dokumentacji (patrz event1 i property2). Umożliwia to ustawienie opcji EXTRACT_ALL w pliku konfiguracyjnym Doxygena, w innym wypadku nie będą one brane pod uwagę. Deklarowanie funkcji w bloku metod bez umieszczania w nim jej ciała, służy określeniu dodatkowych atrybutów funkcji. Ciało funkcji zostało zdefiniowana w oddzielnym pliku. Dla przykładu (patrz rys. 7) funkcja obj() ma określone atrybuty Static, Private oraz Sealed, choć w bloku classdef nie zdefiniowano jej ciała. Atrybuty te prezentowane są za jej nagłówkiem (rys. 7) w sekcji pełnych opisów elementów klasy. Grafy dziedziczenia klas zgodne ze standardem UML Jednym z celów omawianego projektu było zapewnienie możliwości tworzenia dla Matlaba grafów klas zgodnych z UML. Poniżej przedstawiono graf dziedziczenia generowany przez opracowany przez autorów moduł wbudowany go do Doxygena: Graf o strukturze zaprezentowanej na rys. 8 jest dołączany do dokumentacji każdej klasy. Klasa, w której znajduje się graf dziedziczenia staje się jego korzeniem (klasą prezentowaną najwyżej w hierarchii). Po kliknięciu dowolnego węzła grafu następuje przeniesienie widoku do dokumentacji klasy przez niego Rys. 8. Graf dziedziczenia tworzony dla przykładowego kodu źródłowego Matlab Fig. 8. Inheritance graph build for exemplar ysource code written in Matlab Elektronika 12/

5 reprezentowanej. Każdy węzeł grafu zawiera informacje na temat metod klasy oraz jego pól z uwzględnieniem poziomu dostępu. Poziom dostępu oznaczany jest symbolem zgodnym ze standardem UML. Kody źródłowe dołączane do dokumentacji Opracowany moduł umożliwia umieszczanie w dokumentacji odpowiednio sformatowanych kodów źródłowych. Na rys. 9 przedstawiano kod źródłowy pliku wahadlo2.m po odpowiednim sformatowaniu. Numery linii, w których zadeklarowano elementy klasy wahadlo2 zostały oznaczone (np. dwudziesta ósma dla pola property1 klasy wahadlo2). Ich kliknięcie przenosi widok do pełnej dokumentacji danego elementu. Kolorami oznaczono charakterystyczne struktury języka Matlab oraz słowa kluczowe. Klasy i funkcje globalne zostały dodatkowo powiązane ze swoją pełną dokumentacją oznaczono je kolorem jasno-niebieskim. Rys. 10. Fragment dokumentacji klasy wahadlo2 w formacie PDF Fig. 10. Part of documentation for class wahadlo2 in the PDF format Rys. 9. Sformatowany i dołączony do dokumentacji kod źródłowy pliku wahadlo2.m Fig. 9. Source code of file wahadlo2.m, formatted and add to the documentation Inne formaty wyjściowe Na rysunku 10 przedstawiono przykład fragmentu dokumentacji klasy wahadlo2 w formacie pdf. Format pdf posiada mechanizm generowania powiązań między elementami dokumentacji analogiczny do tego prezentowanego przez format wyjściowy HTML. Format zaprezentowany na rys. 10 zawiera wszystkie informacje, które zdefiniowane były dla formatu HTML. Podsumowanie Do tej pory nie istniało darmowe i otwarte narzędzie generujące kompletną dokumentację dla kodów źródłowych Matlaba zrealizowanych zarówno dla nowych jak i starszych wersji oprogramowania. Dlatego głównym celem projektu było opracowanie programu do automatycznego generowania dokumentacji dla kodów źródłowych matlaba, ze szczególnym uwzględnieniem formatu 124 wyjściowego HTML. Dodatkowo program posiada możliwość generacji grafów klas zgodnych ze standardem UML. Należy podkreślić, że dzięki wykorzystaniu programu Doxygen, jako bazowego generatora dokumentacji uzyskano wiele dodatkowych funkcjonalności. Wykorzystanie gotowych funkcji zautomatyzowało częściowo proces implementacyjny. Stworzono tym sposobem generator dokumentacji dla Matlaba o możliwości zastosowania dla wielu różnych języków programowania i wspierający wiele formatów wyjściowych. Dzięki dostosowaniu się do schematów, jakimi wprowadzano do Doxygena wsparcie dla pozostałych języków programowania, praktycznie wszystkie jego funkcjonalności działają dla języka Matlab, np. generowanie diagramów dziedziczenia zgodnych ze standardem UML. Literatura [1] strona poświęcona narzędziu CppDoc. [2] strona poświęcona narzędziu classdoc. [3] strona poświęcona narzędziu BI Documenter. [4] manual do programu Autoduck. [5] strona poświęcona programowi DB Manual. Elektronika 12/2011

6 [6] strona poświęcona programowi dbdesc. [7] strona promocyjna programu DBScribe. [8] specyfikacja języka D i wbudowanego w niego generatora dokumentacji. [9] strona poświęcona narzędziu devscribe. [10] strona poświęcona programowi Doc-O-Matic. [11] strona główna programu DOC++. [12] strona promocyjna narzędzia Document! X. [13] strona poświęcona programowi Epydoc. [14] strona poświęcona narzędziu fpdoc. [15] strona poświęcona programowi GenHelp. [16] strona główna poświęcona narzędziu Haddock. [17] strona poświęcona programowi HeaderDoc. [18] strona poświęcona programowi Help Generator. [19] strona poświęcona narzędziu do dokumentacji HyperSQL. [20] strona poświęcona narzędziu Imagix 4D. [21] strona poświęcona narzędziu Javadoc. [22] strona poświęcona narzędziu jgrousedoc. [23] strona poświęcona narzędziu JSDoc. [24] strona poświęcona narzędziu JsDoc Toolkit; [25] strona główna programu KDOC. [26] strona poświęcona programowi Natural Docs. [27] strona główna poświęcona narzędziu NDoc. [28] strona poświęcona programowi phpdocumentor. [29] strona poświęcona programowi php- SimpleDoc. [30] strona poświęcona programowi Project Analizer. [31] strona poświęcona programowi RDoc. [32] strona poświęcona programowi ROBODoc. [33] strona poświęcona programowi TwinText. [34] strona poświęcona programowi Universal Report. [35] strona poświęcona programowi VB- DOX. [36] strona poświęcona programowi VSdocman. [37] strona poświęcona programowi YARD; [38] strona poświęcona programowi VHDLDOC. [39] strona poświęcona programowi M2HTML. [40] doxygen_manual pdf podręcznik do programu Doxygen. [41] strona poświęcona programowi Enterprise Architect. [42] matlab/bqr_2pl.html strona poświęcona nauce programowania w Matlabie. [43] podręcznik do Bisona. [44] podręcznik do Flexa po polsku. Możliwości rozszerzania satelitarnych systemów radiokomunikacyjnych w GMDSS dr hab. inż. Jerzy Czajkowski, Prof. AM Akademia Morskia w Gdyni, Katedra Eksploatacji Statku Podczas obrad XV sesji Podkomitetu COMSAR w marcu 2011 r. prowadzono rozważania dotyczące możliwości włączenia nowych radiokomunikacyjnych systemów satelitarnych do systemu GMDSS. Jak wiadomo od samego początku tworzenia systemu GMDSS satelitarny system radiokomunikacyjny INMARSAT jest jedynym systemem, który oprócz realizacji radiokomunikacji umożliwia wysyłanie sygnałów alarmowych. W związku z tym definicja obszaru morza A3 odnosi się do obszaru kuli ziemskiej, na której możliwe jest prowadzenie komunikacji alarmowej wykorzystując do tego celu satelity geostacjonarne systemu INMARSAT [1]. Obszar ten zawarty jest pomiędzy 70º szerokości geograficznej północnej oraz 70º szerokości geograficznej południowej. Grupa ekspertów IMO w [2, 3] wyraziła poparcie dla rozwoju regionalnych operatorów satelitarnej radiokomunikacji i możliwości ich wprowadzenia do systemu GMDSS. Na bazie poparcia takiej idei Morski Komitet Bezpieczeństwa (MSC) IMO zlecił Podkomitetowi COMSAR w ramach prowadzenia prac studyjnych nad opracowaniem modernizacji podsystemów i procedur w systemie GMDSS również rozpatrzenie możliwości włączenia nowych radiokomunikacyjnych systemów satelitarnych do GMDSS. Jednym z takich systemów radiokomunikacji satelitarnej jest system Thuraya. W dalszej części przedstawiono zasadnicze uwarunkowania i założenia techniczno-operacyjne tego systemu [4]. Aktualnie system Thuraya dysponuje dwoma satelitami operacyjnymi umieszczonymi na orbicie geostacjonarnej i tak: Satelita Thuraya 2 na pozycji 44º długości geograficznej wschodniej i zapewnia pokrycie radiowe krajom Europy, Afryki i Centralnej oraz Południowej Azji. Satelita Thuraya 3 na pozycji 98,5º długości geograficznej wschodniej i zapewnia pokrycie radiowe azjatyckiego rejonu Oceanu Wielkiego. Trzeci satelita w systemie jest planowany w niedalekiej przyszłości. Tego rodzaju rozmieszczenie satelitów umożliwia uzyskanie pokrycia radiowego globu Ziemskiego. Pomiędzy 75º szerokości geograficznej północnej oraz 75º szerokości geograficznej południowej ograniczone do 30º długości geograficznej zachodniej i 170º długości geograficznej wschodniej. Oznacza to, iż system Thuraya pokrywa swoim zasięgiem radiowym ok. 2/3 powierzchni globu. W odniesieniu do widma częstotliwości zgodnie z ustaleniami Światowej Konferencji Radiokomunikacyjnej z 1997 roku dla Morskiej Służby Ruchomej przyznano na zasadzie pierwszej ważności następujące pasma częstotliwości: MHz oraz 1625,51660,5 MHz. W systemie Thuraya zastosowano następujące pasma częstotliwości: dla kanałów komunikacyjnych: a) MHz dla kierunku Kosmos-Ziemia b) 1626,51660,5 MHz dla kierunku Ziemia-Kosmos, dla kanałów dostępu sygnalizacji: a) MHz na kierunku Kosmos-Ziemia b) MHz na kierunku Ziemia-Kosmos. Elektronika 12/