AKADEMIA GÓRNICZO-HUTNICZA

Transkrypt

1 AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI Event Visualizator - koncepcja systemu wersja 1.4 z dnia Kierunek, rok studiów: Informatyka, II rok Studia niestacjonarne SUM Przedmiot: Inżynieria oprogramowania Prowadzący zajęcia: mgr. Witold Rakoczy Autorzy: Michał Różycki michal.rozycki@gmail.com telefon Rafał Sadłowski rafal.sadlowski@gmail.com Sebastian Falkus sebastian.falkus@gmail.com Jakub Wasiluk wasiu82@gmail.com Rok akademicki: 2010/2011 Semestr: letni Kraków,

2 Niniejsze opracowanie powstało w trakcie i jako rezultat zajęć dydaktycznych z przedmiotu wymienionego na stronie tytułowej, prowadzonych w Akademii Górniczo-Hutniczej w Krakowie (AGH) przez osobę (osoby) wymienioną (wymienione) po słowach "Prowadzący zajęcia" i nie może być wykorzystywane w jakikolwiek sposób i do jakichkolwiek celów, w całości lub części, w szczególności publikowane w jakikolwiek sposób i w jakiejkolwiek formie, bez uzyskania uprzedniej, pisemnej zgody tej osoby (tych osób) lub odpowiednich władz AGH. Copyright 2011 Akademia Górniczo-Hutnicza (AGH) w Krakowie Spis treści 1. Wstęp Przypadki użycia systemu Diagram przypadków użycia Scenariusze wybranych przypadków użycia Architektura systemu Elementy składowe systemu Zasada działania Diagram komponentów Serwer aplikacji Baza danych Logika części serwerowej Webservice interface Klient aplikacji Google Maps Adapter Klient webowy Implementacje systemu EPharmacy Wyszukiwarka usług Zakończenie Bibliografia Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

3 1. Wstęp Przedmiotem pracy jest projekt i implementacja systemu rozproszonego służącego do wizualizacji zdarzeń na mapie. Produkt ten ma na celu udostępnić użytkownikowi końcowemu gotowy, modularny system, pozwalający na wyszukiwanie, zestawianie, filtrowanie zdarzeń/danych dla danej dziedziny problemu. Zdarzenia powiązane są z określonym miejscem i czasem wystąpienia. Podstawowym założeniem platformy jest elastyczność budowy oraz ogólny poziom abstrakcji by można było na jej podstawie zbudować rożne rodzaje aplikacji docelowych. Platforma daje możliwość realizacji różnych rodzajów aplikacji, przykładowo: wizualizację dostępności danego produktu w sklepach wizualizacja półek hal magazynowych dużego spedytora; wizualizacja interesujących turystycznie miejsc wyszukanie interesujących nas zdarzeń powiązanych z miejscem wyszukanie i umiejscowienie egzemplarzem interesującego nas produktu itp. Dokładny opis wymagań funkcjonalnych/niefunkcjonalnych przedstawiony został w dokumentacji wizji systemu. W celu przykładu na bazie istniejących komponentów zaimplementowany został system wizualizacji dostępności leków w danym mieście, oraz system przedstawiający oferty usługowe na terenie całego kraju. Dokument podzielony został na rozdziały opisujące budowę poszczególnych elementów platformy. Opis, scenariusze wybranych przypadków użycia zostały przedstawione w rozdziale 2. Ogólna zasada działania, rola poszczególnych komponentów, opis części składowych systemu, możliwości i ograniczeń przedstawione zostały w rozdziale 3. Rozdział 4 zawiera szczegółowy opis budowy części serwerowej w tym części bazodanowej, wraz z niezbędnymi schematami ułatwiającymi interpretacje. Piąty rozdział opisuje docelowego klienta aplikacji. Historia zmian Opis Wersja Opis Autor Szablon dokumentu, ogólny opis JW, SF elementów składowych Opis architektury systemu oraz MR, SF części serwerowej Dodanie rozdziału dla części RS klienta Rozdział opisujące przypadki MR, RS użycia, końcowe poprawki Bibliografia, referencje do części implementacji systemu, poprawa stylów dokumentu MR Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

4 2. Przypadki użycia systemu Na podstawie zbioru wymagań funkcjonalnych, założeń systemu, dziedziny rozpatrywanego problemu zostały zaprojektowane przypadki użycia oraz scenariusze ich wykorzystania Diagram przypadków użycia Przypadku użycia systemu Event Visualizator można podzielić na trzy zasadnicze grupy: Przeglądanie zdarzeń na mapie, przypadek ten umożliwia wizualizacje zdarzeń na mapie dla danego regionu, podgląd zdarzenia znajduje się na liście znalezionych zdarzeń, dodatkowo funkcja umożliwia filtracje zdarzeń według kategorii, słów kluczowych. Funkcjonalność dostępna dla wszystkich. Edycja zdarzeń, umożliwia dodanie nowych zdarzeń na mapie, dodanie nowych kategorii, słów kluczowych, dodanie lokalizacji, opisu lokalizacji i zdarzenia. Dodatkowo możliwe jest usunięcie oraz edycja zdarzenia/lokalizacji. Edycja kont, funkcjonalność ta możliwa jest do wykonania jedynie przez administratora systemu, w jej skład wchodzi rejestracja nowego konta użytkownika, usunięcie, aktualizacja konta. Rysunek 2.1 Diagram przypadków użycia Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

5 2.2. Scenariusze wybranych przypadków użycia Przeglądanie zdarzeń na mapie System powinien umożliwić dowolnemu użytkownikowi systemu podgląd, wyszukiwanie oraz filtracje zdarzeń, wyniki powinny zostać zobrazowane na mapie, użytkownik powinien mieć możliwość interakcji z mapą. Rysunek 2.3 Przeglądanie zdarzeń Wymaganie Poziom ważności Typ przypadku użycia Aktorzy Krótki opis Warunki wstępne Warunki końcowe Główny przepływ zdarzeń Alternatywne przepływy Notatki i kwestie Przeglądanie zdarzeń na mapie Ważny Interakcja z mapą Administrator, użytkownik, internauta Wyszukiwanie, filtracja, podgląd zdarzeń Osoba musi wyświetlić stronę główną systemu Event Visualizator Wyniki zostają wizualizowane na mapie Wejście na stronę systemu Wprowadzenie szukanego tekstu do formularza z parametrami wyszukiwania, rozwinięcie danej kategorii, wybranie danego słowa kluczowego System powinien walidować dane System powinien zaprezentować wyniki na mapie oraz w liście znalezionych zdarzeń W przypadku błędu walidacji danych zwrócony zostanie komunikat o poprawieniu danych Brak Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

6 Rejestracja użytkownika System powinien umożliwić administratorowi stworzenie nowego konta, pod warunkiem ze szczegółowe dane personalne nowej osoby, która będzie go prowadzić zostaną potwierdzone. Rysunek 2.2 Rejestracja użytkownika Wymaganie Poziom ważności Typ przypadku użycia Aktorzy Krótki opis Warunki wstępne Warunki końcowe Główny przepływ zdarzeń Alternatywne przepływy Notatki i kwestie Rejestracja użytkownika Ważny Zarządzanie użytkownikami Administrator Rejestracja nowego użytkownika Administrator musi posiadać potwierdzenie danych nowej osoby System dodane nowego użytkownika Logowanie do systemu Otrzymanie potwierdzenia o danych nowego użytkownika Administrator wypełnia dane nowego użytkownika w formularzu Wybierany jest rodzaj konta Tworzone jest nowe konto użytkownika Podsumowanie o nowym koncie pamiętnika przesyłane jest drogą elektroniczną do zainteresowanego użytkownika Weryfikacja zostaje odrzucona Brak Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

7 3. Architektura systemu System zaprojektowany został na bardzo ogólnym poziomie abstrakcji dzięki czemu można tworzyć różne rodzaje aplikacji o różnym poziomie złożoności. Na bazie gotowych komponentów/modułów można w elastyczny, prosty sposób budować rozwiązania zawierające złożoną funkcjonalność biznesową, jest to jedno z głównych założeń systemu Elementy składowe systemu Platforma zawiera zbiór kluczowych komponentów wyodrębnionych dla dziedziny problemowej jaką jest wizualizacja zdarzeń na mapie. Komponenty można podzielić na: część kliencka aplikacji w jego skład wchodzi strona internetowa wydzielona jako komponent oraz moduł adaptera mapy Google Maps baza danych, przechowująca informacje o zdarzeniach, czy użytkownikach systemu, baza jest wydzielonym elementem systemu cześć serwera aplikacji, w jego skład wchodzi web serwis, logika wyszukiwania, selekcji, filtracji zdarzeń Zadaniami części klienckiej jest wizualizacja danych, zdarzeń na mapie, w części tej występuje bezpośrednia interakcja z użytkownikiem końcowym. Zadaniem części serwerowej jest zarządzanie, obsługa zapytań danymi części klienta aplikacji, komponent ten zawiera parametryzowaną obsługę logiki Zasada działania Podstawę systemu stanowi wymiana komunikatów, dlatego w celu ujednolicenia komunikatów wykorzystany został jeden wspólny format XML. W komponentach gdzie dana komunikacja występuje stworzone zostały obiekty generujące/parsujące format XML. Zdarzenia generowane przez użytkownika końcowego (np. na mapie, czy poprzez formularze na stronie internetowej) transformowane są do formatu XML, a dalej przesyłane przez protokół SOAP do web serwisu części serwerowej. Następnie komunikaty te zostają parsowane oraz wywoływane poszczególne akcje logiki serwerowej. Zdefiniowane warunki logiczne i wydajnościowe konstruują zapytania do bazy danych, a wyniki tym samym kanałem zostają zwracane do klienta aplikacji. Komunikacja klient-serwer odbywa się przez SOAP, w warstwie transportowej HTTP. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

8 Istotną role stanowi komunikacja pomiędzy stroną internetową a adapterem mapy, komunikacja odbywa się przez zdalne wywoływanie obiektów JavaScript. Sam element adaptera mapy zaimplementowany został technologii Adobe Flex, aplikacja adaptera mapy komunikuje się ze stroną internetową poprzez możliwości obiektu ExternalInterface modułu mapy Diagram komponentów Niżej przedstawiony został diagram bazowych komponentów systemu Event Visualizator. Komunikacja interfejsu ServerInterface odbywa się przez SOAP, w warstwie transportowej HTTP. Komunikacja pomiędzy stroną internetową a adapterem mapy (interfejs IMapAdapter) realizowana jest przez JavaScript (obiekt ExternalInterface biblioteki bazowej Flex). Rysunek 3.1 Diagram głównych komponentów systemu Szczegółowy opis poszczególnych elementów składowych, komponentów systemu przedstawiony został w dalszych rozdziałach. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

9 4. Serwer aplikacji Serwer aplikacji stanowi jeden z kluczowych komponentów systemu, w jego skład wchodzi web serwis ze zdefiniowanym interfejsem biznesowym (dowolnego wykorzystania przez aplikacje klienta), logiką systemu wyszukiwania, selekcji danych, oraz częścią bazodanową Baza danych Wykorzystana została baza danych MySql w wersji 5.1, jest to wydajna i szybka baza, szczególnie dedykowana dla tego rodzaju aplikacji. Struktura bazy została zaprojektowana na tyle ogólnie by mogła uwzględniać wiele rodzajów docelowych aplikacji. Tabela Event posiada informacje o określonym zdarzeniu (nazwa, opis, czas wystąpienia, własność itd.) jest to jedna z kluczowych tabel będąca w ścisłym powiązaniu z tabelą EventLocation zawierającą informacje o lokalizacji zdarzenia (nazwa, adres, miasto, opis, pozycja na mapie itd.). Istotne jest to ze w jednej lokalizacji może znajdywać się wiele zdarzeń (relacja jeden do wielu) dzięki temu można było realizować aplikacje typu dostępność przedmiotów w danej lokacji. Tabela Tag oraz TabMapping zawiera informacje o słowach kluczowych dla danych zdarzeń. Tabela Tag zawiera słowa kluczowe, natomiast tabela TagMapping stanowi tabele pośredniczącą z Event, dzięki temu wiele zdarzeń może posiadać wiele słów kluczowych. Kategoryzacja zdarzeń została rozwiązana przy pomocy tabel Category oraz CategoryMapping. Tabela Category zawiera informacje o nazwie kategorii, opisie, pozycji w poziomie kategorii oraz informacje o identyfikatorze kategorii rodzica dzięki czemu można budować struktury wielopoziomowe (kategorie wielopoziomowe). Tabela CategoryMapping jest tabelą pośredniczącą, dzięki temu wiele zdarzeń może przynależeć do wielu kategorii. Tabela User, oraz UserType zawiera informacje o użytkownikach czy administratorach systemu, wykorzystywana jest do autoryzacji użytkowników. Szablon struktury bazy danych wyeksportowany został do skryptu build.sql podczas instalacji należy uruchomić skrypt na docelowej bazie danych. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

10 Rysunek 4.1 Schemat bazy danych systemu 4.2. Logika części serwerowej Cześć serwerowa jest wydzielonym komponentem systemu, bierze odpowiedzialność za obsługę zapytań generowanych przez aplikacje kliencką. Logika serwera ma zapewnić efektywną i wydajną prace na bazie danych (przykładowo gdy odpowiedzi jest zbyt wiele dokonuje inteligentniej selekcji danych i zwraca najbardziej dopasowane wyniki). Cześć ta została napisana w PHP 5, interfejsem na którym wykonywane są zapytania jest ServerInterface szczegółowo omówiony w podrozdziale 4.3. Kluczową klasą aplikacji Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

11 jest ActionController implementujący interfejs ServerInterface. Klasa ta odpowiedzialna jest za wykonywanie odpowiednich akcji, logiki/walidacji zapytań czy zwracania wyników. Klasa DataBaseController odpowiedzialna jest za obsługę połączenia z bazą danych oraz wykonywanie zapytań bezpośrednio na bazie. Klasa ConfigurationSchema definiuje konfiguracje części serwera np. adres bazy czy limity do wyszukiwania wyników (administrator systemu na stronie klienckiej może dokonać konfiguracji serwera). Klasy XmlFactory oraz MessageController służą do generowania/parsowania komunikatów. Ważną klasą jest klasa SerachController zawierająca warunki wyszukiwania wyników przykładowo gdy użytkownik szuka po słowach kluczowych, adresie lokacji, cenie produktu. Rysunek 4.2 Diagram klas komponentu części serwerowej 4.3. Webservice interface Interfejsem rozdzielającym cześć kliencką od serwerowej jest ServerInterface został on zaimplementowany jako Web serwis przy pomocy darmowej biblioteki PHP NuSOAP. Zastosowanie Web serwisu pozwala na dużą elastyczność rozwiązania przykładowo Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

12 klient napisany pod dowolną platformie może korzystać z aplikacji serwerowej. Interfejs zawiera metody takie jak InsertEvent, Search, getcategory itd. Stanowiące podstawę do obsługi zapytań. Na rysunku 4.3 przedstawiony został zrzut ekranu Web serwisu wraz z opisanymi metodami, typami wymaganych danych. Rysunek 4.3 Zrzut ekranu dla interfejsu Web serwisu ServerInterface Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

13 5. Klient aplikacji Klient aplikacji odpowiedzialny jest za obsługę wizualizacji zdarzeń (wyświetlania, edycji, filtracji) oraz autoryzacje użytkowników, wchodzi w bezpośrednią interakcję z klientem docelowym (administrator, użytkownik systemu, gość). Klient ten może zostać zaimplementowany na dowolnej platformie byle implementował interfejs ServerInterface. W tym przypadku klientem aplikacji jest strona internetowa osadzająca adapter mapy Google Maps Adapter W celu wizualizacji zdarzeń na mapie zaimplementowany został adapter posiadający instancje mapy GoogleMaps, dzięki takiemu rozwiązaniu można było personalizować mapę do konkretnego rozwiązania. Adapter mapy odpowiedzialny jest np. za wizualizacje wyników na mapie, wyniki przybliżane są do punktów granicznych (dzięki czemu można uzyskać inteligentne przybliżenie), edycje punktów, dodanie nowych punktów itd. Adapter zaimplementowany został w technologii Adobe Flex przy wykorzystaniu biblioteki GoogleMaps API, zastosowanie technologii Flex pozwoliło na elastyczne wydzielenie funkcjonalności mapy dla dziedziny problemowej do poszczególnych klas, dzięki czemu uproszczona zostaje późniejsza implementacja adaptera. Interfejs IMapAdapter zawiera zestaw metod do obsługi funkcjonalności mapy, zastosowanie obiektu biblioteki Flex ExternalInterface pozwoliło na wydajną komunikacje z JavaScript osadzonym na stronie internetowej. Klasa JsController implementuje interfejs IMapAdapter odpowiedzialny za delegacje wywołań metod na mapie. Obiekt Communicator implementuje interfejs ServerInterjace służący do komunikacji z serwerem wykorzystujący biblioteki Flex RPC. Klasa XMLParesr służy do generowanie/parsowania XML komunikacji interfejsu IMapAdapter i IServerInterface. Bazową klasą posiadającą instancje mapy Google Maps jest MapContainer, zawiera ona metody do podstawowej obsługi mapy np. buildmarkers (budowanie punktów na mapie), onmapready (zwraca event gdy mapa jest zainicjalizowana), OnMapClick (zwraca event gdy użytkownik kliknie na mapę). Klasą dziedzicząca jest MapAdapter zawierająca uzupełniony zestaw metod do obsługi mapy np. edit (tryb edycji mapy), clickmarker (zdarzenie kliknięcia na punkt mapy), displaysearch (wyświetlanie wyników szukania na mapie) itd. Klasami pomocniczymi są klasy ResultMarker, ResultEvent zawierając struktury danych dla konkretnego punktu na mapie. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

14 Rysunek 5.1 Diagram klas komponentu adaptującego mapę Google Maps 5.2. Klient webowy Aplikacją klienta jest strona internetowa osadzająca instancje komponentu MapAdapter, na której wywoływane są metody interfejsu IMapAdapter. Strona ta została zaimplementowana w języku PHP 5 przy wykorzystaniu wzorca projektowego MVC. Według założeń wzorca MVC oddzielne funkcje systemu zostały wydelegowane do osobnych klas tzn. klasa Controller odpowiedzialna jest za wywoływanie akcji w zależności od zachowania użytkownika (metoda executeuseraction), posiada bezpośrednie instancje klasy Model oraz View. Dzięki metodzie settemplateparameters możliwe jest zdefiniowanie odpowiedniego szablonu dla strony oraz jej wyświetlenie. Klasa Model odpowiedzialna jest za obsługę danych w aplikacji, posiada ona bezpośrednie połączenie z ServerInterface dzięki czemu może pobierać/wysyłać dane do serwera systemu (przykładowo metoda getcategory pobiera dane dotyczące kategorii zdarzeń). Dzięki obiektowi SOAPClient możliwe było skorzystanie z technologii web serwisowej. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

15 Klasa View odpowiedzialna jest za obsługę elementów wyświetlanych na stronie poprzez zastosowanie metod getmapadapter, getvaluefromelement itd. możliwe jest efektywne zarządzani szablonami generowanych stron poprzez obiekt Controller. Kasa View jest w kompozycji z klasą MapAdapter zawierającą instancje mapy oraz metody JavaScript niezbędne do komunikacji. Do prasowania odpowiedzi interfejsu IMapAdapter zastosowana została biblioteka jquery. Instancja klasy AuthorizationManager odpowiedzialna jest za obsługę sesji, autoryzacje użytkowników systemu (np. administrator, zwykły użytkownik, gość). Rysunek 5.2 Diagram klas klienta strony internetowej Zastosowanie modelu MVC czyni klienta aplikacji bardziej elastycznego na zmiany, w prosty sposób można zbudować własnego klienta (czy dodawać własne szablony stron) na bazie istniejącego rozwiązania. Klient aplikacji jest jedynym komponentem który ulega zmianie w zależności od rodzaju docelowej aplikacji. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

16 Przebieg wprowadzenia nowego zdarzenia Rysunek 5.3 Diagram sekwencji dla wprowadzenia nowego zdarzenia na mapie Na rysunku 5.3 przedstawiony został diagram sekwencji dla funkcjonalności wprowadzenia nowego zdarzenia na mapie, funkcjonalność ta składa się z następujących etapów: Użytkownik klika na mapę i zaznacza punkt lokalizacji Obiekt klasy MapAdapter tworzy nową instancje ResultMarker zawierającą współrzędne markera na mapie Obiekt MapAdapter wykonuje funkcje onmapclick na obiekcie JsController, a następnie przekazuje poprzez ExternalInterface metodę callbackinsertpoint do Javascript na stronie internetowej Kolejno wywoływana jest metoda showform wyświetlająca formularz do wprowadzenia danych Gdy użytkownik wypełni formularz wykonywana zostaje metoda additem ze zdefiniowanymi parametrami Następnie obiekt JsController wywołuje na web serwisie metodę InsertEvent Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

17 Serwer aplikacji wywołuje metodę z parametrami na bazie danych, a następnie oczekuje na wynik zapytania SQL Odpowiedz o rezultacie dodania zdarzenia danych przekazywana jest metodą resultmessage do JsController, a następnie poprzez ExternalInterface do Javascript na stronie Strona wyświetla rezultat wprowadzonych danych Przykład ten prezentuje jedną z wielu funkcjonalności systemu jaką jest wprowadzeni nowego zdarzenia. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

18 6. Implementacje systemu Dla przykładu na bazie istniejących komponentów zaimplementowany został system do wizualizacji dostępności leków w danym mieście oraz system przedstawiający oferty usług na terenie całego kraju. Konkretne wybrane przypadki użycia systemu zostały opisane w rozdziale drugim EPharmacy System służy do wizualizacji dostępności produktu (w tym przypadku leków). Każda zdefiniowana apteka może posiadać wiele leków podzielonych na kategorie, posiadających swoje unikalne słowa kluczowe. Możliwa jest autoryzacja poprzez logowanie czy rejestracje nowych użytkowników. Testowy adres systemu: testphp.endq.eu/io/clientpharmacy Adres web serwisu części serwerowej: testphp.endq.eu/io/server/serverinterface.php Rysunek 6.1 Zrzut ekranu systemu EPharmacy strona gówna Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

19 Rysunek 6.2 Zrzut ekranu systemu EPharmacy edycja 6.2. Wyszukiwarka usług Kolejną implementacją jest system służący do wizualizacji usług w obrębie całego kraju. Każda usługa powiązana jest z tylko jednym miejscem, użytkownik ma możliwość szukania usługi lub wyświetlania usług po danych słowach kluczowych. Możliwa jest autoryzacja użytkowników (rysunek 6.3) Testowy adres systemu: testphp.endq.eu/io/clientservice Adres web serwisu części serwerowej: testphp.endq.eu/io/serverservice/serverinterface.php Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

20 Rysunek 6.3 Zrzut ekranu systemu Wyszukiwarka usług edycja Klientem systemu jest firma która dostosuje obecne rozwiązanie wizualizacji zdarzeń do swoich potrzeb. W rozdziale szóstym opisane zostały przykładowe implementacje systemu, opis wszystkich kroków implementacji (dla przykładu wizualizacji leków EPharmacy) znajduje się w dokumencie podręcznik programisty. Podręcznik programisty zawiera kompletny przewodnik jak i w jaki sposób skorzystać z bazowych komponentów by zbudować własny system do wizualizacji zdarzeń. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

21 7. Zakończenie Dokument ten zawiera opis idei rozwiązania systemu dla problemu wizualizacji zdarzeń na mapie. Została opisana architektura, komponenty składowe, interfejsy komunikacyjne. System został zaprojektowany na ogólnym poziomie abstrakcji, by można było na jego podstawie budować własne różne rodzaje konkretnych aplikacji. System został wydzielony na moduły funkcjonalne realizujące pewien zbiór funkcjonalności dziedziny problemu, to co specyficzne zostało wydzielone do komponentu strony internetowej. Zastosowanie technologii web serwisowej pozwoliło oddzielić część klienta od serwera, dzięki temu implementacja dowolnej części jest niezależna od drugiej i może zostać zaimplementowana w różnych technologiach. Takie podejście umożliwia elastycznie i efektywnie budować własne rozwiązania do wizualizacji zdarzeń. Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia

22 8. Bibliografia [1] Rakoczy W., Żabińska M.: Redagowanie dokumentacji projektowej, opracowanie wewnętrzne Katedry Informatyki AGH, wersja 0.1-1, Kraków, 2000, ( [2] Google Map API for Flash ( Plik: Event Visualizator - koncepcja v.1.4 Wersja 1.4 z dnia