praca magisterska · open handset alliance (oha). celem oha jest wspieranie rozwoju otwartych...

AKADEMIA GÓRNICZO-HUTNICZA

IM. STANISŁAWA STASZICA W KRAKOWIE

Wydział Inżynierii Metali i Informatyki Przemysłowej

PROJEKT MAGISTERSKI

pt.

„System wspomagania decyzji w zakresie alokacji zasobów w serwisie

maszyn przemysłowych”

Imię i nazwisko dyplomanta: Mateusz Kaflowski

Kierunek studiów: Informatyka Stosowana

Nr albumu: 240149

Opiekun: dr inż. Krzysztof Regulski

Podpis dyplomanta: Podpis opiekuna:

Kraków 2015

WSPOMAGANIE DECYZJI W ZAKRESIE ALOKACJI ZASOBÓW

2

Oświadczam, świadomy(-a) odpowiedzialności karnej za poświadczenie

nieprawdy, że niniejszy projekt inżynierski wykonałem(-am) osobiście

i samodzielnie i że nie korzystałem(-am) ze źródeł innych niż wymienione

w pracy.

Kraków, dnia ………….… Podpis dyplomanta…………….

praca magisterska -Mateusz Kaflowski

3

SPIS TREŚCI:

1. Wprowadzenie ...................................................................................................................... 5

2. Koncept technologii agentowej ............................................................................................ 6

3. System operacyjny Android ................................................................................................ 11

4. Dokumentacja systemu ....................................................................................................... 15

4.1. Perspektywa przypadków użycia ................................................................................ 17

4.2. Diagram klas ................................................................................................................ 19

4.3. Diagram aktywności .................................................................................................... 20

4.4. Diagram wdrożenia ..................................................................................................... 22

4.5. Inteligencja systemu ................................................................................................... 23

5. Implementacja .................................................................................................................... 24

5.1. Podział na podprojekty i pakiety ................................................................................. 24

5.2. Diagramy klas i opisy ................................................................................................... 27

5.3. Implementacja najważniejszych procesów ................................................................. 39

6. Działanie programu ............................................................................................................. 53

7. Uwagi końcowe ................................................................................................................... 60

8. Bibliografia .......................................................................................................................... 61


4


5

1. Wprowadzenie

Celem pracy magisterskiej jest stworzenie systemu wspomagania decyzji

w zakresie alokacji zasobów w serwisie maszyn przemysłowych. Głównymi funkcjami

systemu będzie monitorowanie położenia oraz dostępności serwisantów oraz

automatyczne przekazywanie im zleceń. Klient zgłaszający problem nie będzie musiał

wypełniać żadnych formularzy z wyjątkiem opisu problemu oraz adresu. Część

centralna systemu automatycznie rozpozna czego dotyczy wiadomość dzięki

wystąpieniom słów kluczowych oraz automatycznie znajdzie najbliższego serwisanta,

który zajmuje się tą kategorią problemów oraz jest w danym momencie dostępny.

Całość będzie oparta o platformę agentową JADE.

System będzie więc składał się z czterech podprojektów:

- program klienta – PC

- manager komunikacji – PC

- aplikacja serwisanta – Android

- wspólne klasy pozostałych podprojektów do unifikacji komunikacji

Docelowym odbiorcą stworzonego systemu będą firmy zajmujące się serwisowaniem

wszelakich maszyn przemysłowych. Dzięki możliwości modyfikacji słów kluczowych

służących do rozpoznawania kategorii problemu każda z użytkujących firm będzie

mogła dostosować system do swojej dziedziny działania. Poprzez korzystanie z systemu

zostanie zautomatyzowana komunikacja między klientami a serwisantami, dzięki czemu

firmy zajmujące się naprawą maszyn nie będą potrzebowały pracowników zajmujących

się wyłącznie przyjmowaniem zleceń i przekazywaniem ich do konkretnych

serwisantów. Kolejnym atutem korzystania z systemu jest monitorowanie położenia

oraz statusu wszystkich pracowników oraz miejsc, z których pochodzą zlecenia,

co może posłużyć do dalszych analiz usprawniających działanie firmy.


6

2. Koncept technologii agentowej

Agent-Oriented Programming (AOP), czyli programowanie zorientowane na agenty

jest stosunkowo nowym paradygmatem, który w pewien sposób wprowadza teorię

sztucznej inteligencji do głównego nurtu systemów rozproszonych. AOP modeluje

programy jako kolekcję komponentów zwanych agentami, które charakteryzują

się autonomicznością, proaktywnością oraz zdolnością do komunikacji. Dzięki

autonomiczności mogą one niezależnie wykonywać skomplikowane oraz często długie

zadania. Dzięki proaktywności są zdolne do podejmowania pewnych akcji

bez ingerencji użytkownika. Dzięki komunikatywności mogą wchodzić w interakcję

między sobą, aby osiągnąć jakiś wspólny cel. Architektura programu zorientowanego

agentowo staje się samoistnie architektura peer to peer, jeżeli agent jest w stanie

nawiązać komunikację z innym agentem bądź sam jest odbiorcą przychodzącej

komunikacji.

Technologia agentowa była tematem dyskusji oraz badań od wielu lat przed jej

ustandaryzowaniem. W 1996 powstała organizacja Foundation for Intelligent Physical

Agents (FIPA) jest organizacją non-profit skupiającą twórców technologii agentowej

celem utworzenia grupy standardów oprogramowania technologii agentowej.

Technologie agentowe były już wcześniej znane pośród społeczności akademickiej

jednak zainteresowanie nimi ze stron przedsiębiorstw handlowych było mocno

ograniczone. Aby zmienić stan rzeczy, organizacja FIPA postanowiła stworzyć

standardy będące podstawą dla technologii agentowej.

U podstaw FIPA znalazł się następujący zestaw zasad:

1. Technologie agentowe dostarczają nowego paradygmatu, aby rozwiązywać

nowe problemy.

2. Pewne technologie agentowe osiągnęły pewien zadowalający stopień

dojrzałości.

3. Pewne technologie agentowe wymagają standaryzacji, aby mogły być

wykorzystane.

4. Standaryzacja generycznych technologii przez inne organizacje pokazała,

że taka standaryzacja jest możliwa i dostarcza efektywne rezultaty.

5. Standaryzacja wewnętrznych mechanizmów oraz samych agentów nie jest

głównym zadaniem, ale raczej standaryzacja infrastruktury oraz języków

do otwartego współdziałania.


7

Agent w dziedzinie programowania jest rozumiany jako system komputerowy,

zdolny do podejmowania elastycznych, autonomicznych działań w pewnym środowisku

w celu osiągnięcia wydelegowanych celów. Myśląc abstrakcyjnie można przedstawić

agenta jako istotę będącą w ciągłej interakcji z otoczeniem: percepcja - decyzja – akcja.

Przykładem agenta może być termostat, którego wydelegowanym zadaniem jest

utrzymanie określonej temperatury w pokoju, natomiast akcjami są wyłączenie

i włączanie ogrzewania [3].

Przez elastyczne działanie agenta należy rozumieć działanie, które jest:

reaktywne – agent utrzymuje ciągłą interakcję z otoczeniem,

proaktywne – agent dąży do realizacji swoich celów; nie jest sterowany jedynie

przez zewnętrzne zdarzenia, a sam decyduje o swoich działaniach,

socjalne – agent podejmuje interakcje z innymi agentami działającymi

w środowisku.

Inne właściwości, czasami rozważane w kontekście agentów to:

mobilność – zdolność agentów do przemieszczania się w sieci komputerowej,

prawdomówność – agenci nieświadomie udzielają fałszywych informacji,

dobroczynność – agenci nie mają sprzecznych celów, każdy agent próbuje

spełnić wszystkie prośby zgłoszone przez innych agentów,

racjonalność – agenci działają z zamiarem realizacji swoich celów, nie

podejmują żadnych działań, które mogłyby przeszkodzić w osiągnięciu ich –

przynajmniej na tyle ile są o tym przekonani,

uczenie adaptacja – agenci poprawiają swoją sprawność.

Agenta od obiektu odróżniają trzy główne cechy:

agenci są autonomiczni – agent reprezentuje silniejsze pojęcie niezależności

niż obiekt,

agenci są sprytni – agent jest zdolny do elastycznego zachowania,

agenci są aktywni – każdy agent posiada przynajmniej jeden aktywny wątek.

Środowisko, w którym działa agent posiada następujące podstawowe cechy:


8

jest dostępne lub niedostępne – środowisko dostępne to takie, w którym agent

może otrzymać kompletną, dokładną informacje o stanie środowiska,

jest deterministyczne lub niedeterministyczne – środowisko deterministyczne

to takie, w którym każda akcja ma jeden określony rezultat,

jest epizodyczne lub nieepizodyczne – środowisko epizodyczne to takie,

w którym sprawność agenta jest zależna od pewnej liczby dyskretnych

epizodów, bez powiązania między sprawnością agenta przy różnych

scenariuszach,

jest statyczne lub dynamiczne – środowisko statyczne to takie, które nie zmienia

się na skutek akcji agenta,

jest dyskretne lub ciągłe – środowisko dyskretne to takie, w którym istnieje

ustalona, skończona liczba akcji, które można w nim wykonać i stanów, które

można zaobserwować [9].

System wieloagentowy to taki, który składa się z pewnej liczby agentów

oddziałujących ze sobą. Zazwyczaj agenci działają w imieniu użytkowników, z różnymi

celami i zamiarami. Aby pomyślnie oddziaływać, agenci potrzebują zdolności

do współpracy, koordynowania i negocjacji z innymi agentami.

Systemy agentowe są często wykorzystywane do planowania (tzw. planowanie

agentowe). Jest to technika planowania często wykorzystywana w problemach

ze zmieniającym się środowiskiem, m.in. problemach czasu rzeczywistego, gdzie

parametry problemu mogą zmieniać się w czasie obliczeń.

Systemy wieloagentowe są stosowane również, gdy trzeba rozwiązać problemy

o charakterze rozproszonym takich jak wyszukiwanie informacji w sieci [10].

Istnieje wiele frameworków przeznaczonych do tworzenia systemów

agendowych. Jednym z najbardziej rozpowszechnionych jest Java Agent Development

Framework (JADE).

Platforma JADE składa się z kontenerów agentów, które mogą być rozproszone

za pomocą sieci. Agenci działają wewnątrz tych kontenerów, które są procesami JAVA.

Istnieje pewien specjalny kontener nazwany „main conteiner”, który jest punktem

początkowego ładowania platformy. Jest to pierwszy uruchamiany kontener i wszystkie

pozostałe muszą do niego dołączyć poprzez rejestrację w nim.


9

Rysunek 1 – główne elementy architektury [3]

Rysunek 2 - relacje między głównymi elementami architektury [3]

Zaadaptowanym w JADE paradygmatem komunikacji jest asynchroniczne

przekazywanie wiadomości. Każdy agent posiada coś w rodzaju skrzynki pocztowej

(kolejka wiadomości) gdzie środowisko uruchomieniowe JADE zapisuje wiadomości

wysłane przez innych agentów. Ilekroć wiadomość jest zapisywana w kolejce

wiadomości agenta, agent będący adresatem zostaje o tym powiadomiony. To czy


10

wiadomość zostanie w ogóle odczytana i kiedy to się stanie zależy jedynie

od programisty.

Rysunek 3 - paradygmat asynchronicznego przekazywania wiadomości w JADE [10]

Wiadomości wymieniane przez agentów JADE posiadają format określony przez

język ACL (Agent Communication Language), który jest międzynarodowym

standardem dla interoperacyjności agenta i został zdefiniowany przez organizację

Foundation for Intelligent Physical Agents (FIPA). Format ten składa się z wielu pól

a w szczególności z:

nadawcy wiadomości,

listy odbiorców wiadomości,

intencji komunikacji („performative”), wskazującej na to, co nadawca chciał

osiągnąć przez wysłanie wiadomości,

zawartości wiadomości, czyli właściwa informacja zawarta we wiadomości,

języka użytego do stworzenia zawartości (odbiorca oraz nadawca muszą być

zdolni do odczytania wyrażeń składających się na składnie języka użytego

do stworzenia zawartości),

ontologii (na przykład słownik symboli użytych w zawartości i ich znaczenie),

pewnych pól przeznaczonych do kontroli równoczesnych rozmów oraz

określających limity czasowe na otrzymanie odpowiedzi takich jak

conversation-id, reply-with, in-reply-to, reply-by.

Wiadomość w JADE jest implementowana jako obiekt klasy

jade.lang.acl.ACLMessage, która dostarcza metody get i set do obsługi wszystkich pól

wiadomości [2].


11

3. System operacyjny Android

Android jest systemem operacyjnym z rodziny Linux wydanym w 2008 roku przez

firmę Google.

Android został okrzyknięty „pierwszą kompletną, otwartą i darmową platformą

mobilną. Główne cechy Androida to:

kompletność – projektanci podjęli kompleksowe podejście podczas rozwijania

systemu Android. Zaczęli od bezpiecznego systemu operacyjnego tworząc

solidne podstawy, które pozwalały na bogaty rozwój aplikacji

otwartość – kod jest dostępny publicznie

darmowość – każdy może tworzyć aplikacje na urządzenia mobilne z systemem

operacyjnym Android za darmo. Nie występują żadne opłaty licencyjne

ani członkowskie. Cały proces nie wymaga żadnych certyfikatów. Aplikacje

mogą być rozpowszechniane na wiele sposobów [5].

Jeżeli chodzi o wspomnianą wcześniej otwartość należy dodać, że nie jest ona

całkowita. Kod jest rozwijany przez firmę Google, która udostępnia swoje zmiany tylko

przy wydawaniu kolejnych wersji. Powstała więc specjalna inicjatywa stworzenia

w pełni otwartej wersji systemu. Projekt obecnie nosi nazwę Android Open Source

Project (AOSP) [6]. Platforma ta zawiera system operacyjny, oprogramowanie

pośredniczące (middleware) oraz wewnętrzne aplikacje. AOSP jest nadzorowany przez

Open Handset Alliance (OHA). Celem OHA jest wspieranie rozwoju otwartych

standardów dla urządzeń mobilnych. Lista członków OHA zawiera takie firmy jak

Qualcomm, Broadcom, HTC, Intel, Samsung, Motrola, Spirit, Texas Instruments oraz

japońskich operatorów KDDI i NTT DoCoMo. Dzięki projektowi Android Open Source

Project, każdy może pobrać kod źródłowy ze strony https://source.android.com/ oraz

stworzyć własną wersję tego systemu. Jednym z najbardziej popularnych rozwinięć tego

projektu jest CyanogenMod [7,8]. Posiada on wsparcie i dystrybucję dla wielu znanych

urządzeń. Głównymi założeniami systemu jest zwiększenie wydajności oraz

niezawodności. Zawiera on wiele funkcji zarządzających samym sprzętem

niedostępnych w standardowym systemie takie jak na przykład możliwość zwiększenia

wydajności CPU. W listopadzie 2013 roku został udostępniony program przeznaczony

do łatwej instalacji CyanogenModa – CyanogenMod Installer. Dostępny on jest

do pobrania na oficjalnej stronie projektu.

https://source.android.com/


12

Każda aplikacja działająca w systemie działa w osobnym wątku, który jest własną

instancją wirtualnej maszyny Dalvik. Bazując na Java VM, Dalvik został

zoptymalizowany dla urządzeń mobilnych. Dalvik VM posiada małe zużycie pamięci

i wiele jego instancji może działać konkurencyjnie na urządzeniu.

Aplikacje stworzone są z elementów nazywanych komponentami. Każdy

komponent stanowi inny rodzaj punktu, przez który system może dostać się

do aplikacji. Nie wszystkie komponenty jednak mogą być punktem wejścia dla

użytkownika, ale każde z nich istnieje jako samodzielny byt i odgrywa pewną

specyficzną rolę. Wyróżnia się cztery rodzaje komponentów. Każdy z nich posiada inny

cykl życia, który pokazuje działanie komponentu od jego utworzenia aż do utylizacji.

Activity – reprezentuje pojedynczy ekran z interfejsem użytkownika.

Na przykład aplikacja mailowa może posiadać jedną aktywność, która pokazuje

listę wiadomości i inną pokazującą samą wiadomość po jej wyborze.

Rysunek 4 - cykl życia Activity [1]


13

Service – komponent wykonujący długotrwałe operacje w tle dla zdalnych

procesów. Service nie posiada interfejsu użytkownika. Service może na przykład

odtwarzać muzykę, podczas gdy użytkownik dalej swobodnie korzysta z innych

funkcji urządzenia.

Rysunek 5 - cykl życia Service [1]

Content provider – zarządza dzielonymi przez aplikacje zestawami danych.

Dzięki niemu możliwe jest przekazywanie danych między różnymi aplikacjami.

Broadcast receiver – komponent odpowiadający na wiadomości rozgłaszane

po całym systemie. Wiele takich wiadomości pochodzi od systemu (na przykład

wiadomość o słabym stanie baterii lub o przygaszeniu ekranu). Wiadomości

tego typu mogą być też rozgłaszane przez aplikacje niesystemowe. Aczkolwiek

broadcast receivery nie mają interfejsu użytkownika mogą one tworzyć

notyfikacje w pasku powiadomień w celu poinformowania o wystąpieniu

zdarzenia.


14

Zanim aplikacja uruchomi jakikolwiek komponent, system musi wiedzieć o jego

istnieniu poprzez odczytanie go z pliku AndroidManifest.xml. Wszystkie komponenty

aplikacji muszą zostać zadeklarowane w tym pliku, który musi się znaleźć w głównym

katalogu programu [1,2]. Ponadto manifest zawiera takie informacje jak:

identyfikacja zezwoleń wymaganych przez aplikacje takich jak na przykład

dostęp do Internetu,

deklaracje minimalnego poziomu API

deklarację używanych sprzętowych lub systemowych funkcji takich jak

na przykład kamera czy bluetooth

itd.

Dzięki bardzo przystępnemu procesowi tworzenia nowych aplikacji na urządzenia

mobilne powstaje wiele nowych rozwiązań na tę platformę oraz wiele już gotowych

zostaje pod nią przystosowanych. Stało się tak również z biblioteką JADE, która

posiada swoją wersję na ten system operacyjny. Posiadając te rozwiązania oraz

darmową możliwość tworzenia oprogramowania dzięki dostarczonemu przez Google

Android Development Tools (ADT) oraz Android SDK możliwe było zaprojektowanie

oraz stworzenie części projektu przeznaczonej dla serwisantów na urządzenia mobilne

wraz z pełnym wykorzystaniem ich zalet.


15

4. Dokumentacja systemu

Cały system składa się z czterech podstawowych podprojektów:

część klienta – odpowiedzialna za tworzenie i wysyłanie zleceń przez klientów,

manager komunikacji – odpowiedzialna za pośredniczenie, rozpoznawanie

treści oraz przekierowywanie wiadomości; zbiera również informacje na temat

statusów oraz położeń serwisantów,

aplikacja serwisanta – aplikacja końcowa przeznaczona dla serwisantów

napisana dla urządzeń mobilnych z systemem operacyjnym android; służy

do monitorowania serwisantów oraz przekazywania im informacji dotyczących

zleceń,

wspólne klasy pozostałych podprojektów do unifikacji komunikacji.

Wymaganym elementem jest również główna platforma, do której wszyscy

użytkownicy będą się logować oraz przez którą będzie następowała komunikacja

między nimi. W tym przypadku odpowiedzialność za jej utworzenie i utrzymywanie

najlepiej przekazać na część centralną systemu a więc managera komunikacji.

Ze względu na komunikację między agentami, która stanowi najważniejszy

i często wykorzystywany element systemu do opracowania jej wykorzystano platformę

Java Agent Development Framework (JADE), gdzie łączność między agentami jest

bardzo dobrze opracowana. JADE jest oprogramowaniem pośredniczącym, które

ułatwia tworzenie systemów wieloagentowych. Platforma JADE pozwala na proste

i szybkie przesyłanie informacji dowolnego typu między użytkownikami, przy czym

implementacja całego szkieletu komunikacyjnego nie jest bardzo skomplikowana.

Całość programu została napisana w języku JAVA. Dzięki platformie Java Agent

Development Framework możliwe jest zalogowanie się agenta do platformy

nieznajdującej się na lokalnej maszynie posiadając jedynie adres maszyny, na której

ta platforma się znajduje oraz numer wykorzystywanego portu.

Kolejnym ważnym atutem frameworku JADE jest jego wersja opracowana specjalnie

dla systemu Android oraz dostęp do przykładowego projektu utworzonego w celu

łatwego dostosowania się do standardów używanych właśnie w tej platformie. Pomimo

pewnych różnic przy implementowaniu rozwiązań agentowych dla systemów

mobilnych wersja frameworku dla systemu Android współpracuje z frameworkiem

przeznaczonym dla systemów PC.


16

JADE składa się z:

- środowiska uruchomieniowego gdzie są uruchamiane i działają agenty,

- bibliotek zawierających klasy do tworzenia agentów przez programistów,

- graficznych narzędzi służących do administrowania i monitorowania

aktywności działających w systemie agentów.

Ważną zaletą frameforku JADE jest również posiadanie tak zwanych „żółtych

stron” (Yellow Pages). Każdy agent może się w nich zarejestrować podając informacje

o tym, jakie usługi świadczy. Inni agenci mogą uzyskać informacje o wszystkich

agentach świadczących usługi w danym zakresie odwołując się właśnie do Yellow

Pages. Jest to analogia do rejestru usług znajdujących się w książkach telefonicznych.


17

Podstawowe funkcjonalności programu oraz budowa zostały przedstawione poniżej

na podstawie różnego rodzaju diagramów UML obrazujących najważniejsze procesy

składające się na całość działania programu.

4.1. Perspektywa przypadków użycia

a. diagram przypadków użycia:

b. opis aktorów:

Klient – osoba składająca zlecenie na wykonanie naprawy – przekazuje

do systemu jedynie opis oraz adres zlecenia,

Manager – część centralna systemu, zajmuje się zarządzaniem

i przekazywaniem wiadomości od klienta do odpowiedniego serwisanta; jeżeli

w systemie nie zarejestrował się odpowiedni serwisant, kolejkuje wiadomość

i cyklicznie sprawdza aktualnie dostępnych

Serwisant – użytkownik końcowy otrzymujący informację dotyczące zlecenia

na urządzenie mobilne z systemem Android.

Rysunek 6 - diagram przypadków użycia


18

c. dokumentacja przypadków użycia:

Poniżej został opisany najważniejszy przypadek użycia:

Nazwa Wysłanie zlecenia

Aktorzy Klient, manager, serwisant

Udziałowcy/Zainteresowani Klient: wysyła zlecenie

Manager: przyjmuje i przetwarza otrzymane

zlecenie

Serwisant: Odbiera i zapisuje zlecenie

w pamięci urządzenia mobilnego

Krótki opis Przekazanie zlecenia naprawy od klienta do

odpowiedniego serwisanta.

Warunki wstępne Otrzymanie danych od klienta.

Warunki końcowe Zapisanie danych zlecenia w pamięci

urządzenia mobilnego serwisanta.

Główny przepływ zdarzeń 1. Klient opisuje i wysyła zlecenie.

2. Manager identyfikuje otrzymane dane

jako zamówienie.

3. Manager rozpoznaje dziedzinę

zlecenia.

4. Manager znajduję najbliższego

dostępnego serwisanta zajmującego

się rozpoznaną dziedziną.

5. Manager wysyła zlecenie do

odnalezionego serwisanta.

6. Serwisant otrzymuje zlecenie.

7. Serwisant zapisuje zlecenie w pamięci

urządzenia mobilnego.

Alternatywne przepływy zdarzeń 4a. Manager znajduje najbliższego serwisanta

z najbardziej priorytetowym statusem

dostępności.

4b. Manager z powodu braku serwisantów w

danej dziedzinie zakolejkuje je do ponownego

wyszukania specjalisty.

Specjalne wymagania Połączenie wszystkich trzech stron z jedną

platformą JADE.


19

4.2. Diagram klas

Poniżej przedstawiono diagram klas używanych do komunikacji między agentami.

Jest to diagram części wspólnej całego systemu. Diagramy klas pozostałych

podprojektów zostaną przedstawione w dalszej części pracy.

Rysunek 7 - diagram klas modułu komunikacji


20

4.3. Diagram aktywności

a. wysłanie nowego zlecenia przez klienta i dostarczenie go do serwisanta:

Poniżej przedstawiono diagram aktywności dla najważniejszego procesu systemu.

Rozpoczyna się on od utworzenia zlecenia przez klienta a kończy dopiero

w momencie odebrania tego zlecenia przez odpowiedniego serwisanta.

Rysunek 8 - diagram aktywności z wysyłaniem zlecenia


21

b. monitorowanie położenia serwisanta

Poniżej przedstawiono diagram aktywności dla procesu monitorowania położenia

i statusu serwisanta. Zaczyna on się w momencie utworzenia agenta

reprezentującego serwisanta a kończy w chwili usunięcia go z platformy.

Rysunek 9 - diagram aktywności z monitorowaniem serwisanta


22

4.4. Diagram wdrożenia

Poniżej przedstawiono diagram wdrożenia dla całego systemu (podsystem klienta,

podsystem managera, podsystem serwisanta, główna platforma).

Rysunek 10 - diagram wdrożenia


23

4.5. Inteligencja systemu

Głównym celem pracy było stworzenie działającego zestawu powiązanych

ze sobą aplikacji, które dynamicznie reagują na zaistniałe zdarzenia. Zarówno

projekt jak i implementacja uległa znacznemu uproszczeniu dzięki architekturze

zorientowanej na agenty oraz mechanizmom zaimplementowanym w bibliotece

JADE. Na przykład manager wiadomości elastycznie reaguje na zmianę dostępności

oraz położenia serwisantów oraz po otrzymania wiadomości od klienta

w inteligentny sposób podejmuje decyzję, któremu pracownikowi przekazać nowe

zlecenie.

Na rynku istnieją już rozwiązania służące do monitorowania urządzeń

mobilnych takie jak na przykład XNSPY czy mySpy. Są one jednak skierowane

do zupełnie innego odbiorcy, któremu zależy na pozyskiwaniu informacji

o użytkowniku. Stworzony na potrzeby pracy system jest ukierunkowany głównie

na usprawnienie i automatyzację przekazywania informacji między użytkownikami.

Dokładny sposób implementacji został przedstawiony w kolejnych rozdziałach.


24

5. Implementacja

W tej części pracy zostało omówione wszystko, co jest związane z implementacją

i praktycznym opracowaniem całego systemu.

5.1. Podział na podprojekty i pakiety

Cały system został podzielony na cztery części (projekty). Zostały one

wyszczególnione poniżej wraz z ich krótki opisem oraz opisem poszczególnych

pakietów wchodzących w ich skład.

a. projekt CommonSource

Jest to projekt zawierający klasy służące do wspólnej komunikacji między

agentami. Używany jest przez wszystkie pozostałe proejkty. Projekt zawiera

następujące pakiety:

Rysunek 11 - pakiety projektu CommonSource

pakiet communication

Jest to pakiet zawierający klasy reprezentujące wiadomości. Mogą one być

serializowane dzięki czemu instancje tych klas mogą być przesyłane przez sieć.

pakiet structures

Klasy wykorzystywane przez klasy wiadomości z pakietu communication. Służą

do reprezentowania danych takich jak na przykład położenie geograficzne

czy infromacje dotyczące użytkowników systemu.

b. projekt ClientProgram

Jest to projekt zawierający implementację części końcowej dla klientów.

Program klienta służy do łączenia się z główną platformą oraz przekazywnie

jej wprowadzonych przez użytkownika zleceń. Projekt zawiera następujące pakiety:


25

Rysunek 12 - pakiety projektu ClientProgram

pakiet com.google.code.geocoder

Pakiet należący do biblioteki Java API for Google geocoder v3. W tym

projektcie posłużyła ona do odwróconego geokodowania czyli konwersji adresu

na współżędne goegraficzne.

pakiet com.google.code.geocoder.model

Pakiet należący do biblioteki Java API for Google geocoder v3.

pakiet gui

Pakiet zawierający implementację graficznego interfejsu użytkownika.

pakiet system

Jest to pakiet zawierający implementację głównych klas systemu

odpowiedzialnych za integrację wyszystkich klas ze sobą oraz za operacje

na plikach, zarządzanie platformą JADE itp.

c. projekt OrderManager

Jest to projekt zawierający implementację części centralnej systemu. Jest

pośrednikiem między klientem a serwisantem, zarządz wiadomiściami oraz

monitoruje serwisantów. Projekt zawiera jeden pakiet:

Rysunek 13 - pakiety projektu OrderManager

pakiet manager

Pakiet zawiera kompletną implementację całego podsystemu części centralnej

wraz z integracją z platformą JADE, zachowaniami niezbędnymi do działania systemu

oraz algorytmami rozpoznawania kategorii zlecenia oraz wyszukiwania najbardziej

odpowiedniego serwisanta wraz zprzekazaniem do niego wiadomości


26

d. projekt AndroidExpert

Jest to projekt zawierający implementację części końcowej dla serwisantów

w wersji mobilnej. Aplikacja serwisanta służy do łączenia się z główną platformą,

odbierania zleceń od klientów, zarządznia nimi oraz wysyłania do części centralnej

informacji dotyczących dostępności serwisanta oraz jego położenia. Ze względu

na większą złożoność tego podprojektu klasy zostały podzielone na dokładniej

je opisujace pakiety niż to miało miejsce w pozostałych podprojektach. Projekt

zawiera następujące pakiety:

Rysunek 14 - pakiety projektu AndroidExpert

pakiet agent

Jest to pakiet zawierający implementację klasy agenta oraz klasy zarządzającą

tym agentem.

pakiet agent.behaviour

Jest to pakiet zawierający implementację zachowań agenta takich jak

na przykład wysyłanie wiadomości zawierającej położenie czy odbieranie

wiadomości od klienta.

pakiet features

Jest to pakiet zawierający implementację dodatkowych funkcjonalnośći

używanych w podprojekcie.

pakiet gui

Jest to pakiet zawierający implementację graficznego interfejsu użytkownika

(zarówno aktywności jak i adapterów).


27

5.2. Diagramy klas i opisy

Ze względu na liczbę klas diagram podzielono na podprojekty bądź na pakiety

z poszczególnych podprojektów. W tej części pracy zostały również omówione

poszczególne klasy całego programu wraz z podziałem ich na pakiety. Poniżej

uwzględniono jedynie najważniejsze pola i metody klas.

a. projekt CommonSource

Rysunek 15 - diagram klas projektu CommonSource


28

Pakiet communication składa się z następujących klas:

Message - klasa służąca do komunikacji między agentami. Podstawowy typ

wiadomości. Implementuje interfejs Serializable w celu możliwość przesyłania

instancji w platformie JADE oraz zapisu obiektów na dysku twardym.

MessageType – typ wyliczeniowy reprezentujący rodzaj wiadomości. Używany

w klasie Message do identyfikowania typu wiadomości.

Dostępne wartości MessageType:

MESSAGE, REGISTRATION, DEREGISTRATION, LOCATION, ORDER, EXPERT_MESSAGE.

Order - wiadomość zawierająca zlecenie od klienta. Rozszerza klasę Message

o takie elementy jak tytuł, treść oraz status zlecenia.

OrderStatus - typ wyliczeniowy reprezentujący status zlecenia. Używany w klasie

Order.

Dostępne wartości OrderStatus:

NEW, IN_PROGRESS, DONE.

ExpertMessage – wiadomość domyślnie nadawana przez serwisanta. Rozszerza

klasę Message o informacje dotyczące serwisanta w postaci instancji klasy Expert

Data.

Pakiet structures składa się z następujących klas:

ExpertData – klasa przechowująca informacje na temat serwisanta takie

jak na przykład jego nazwa, status, specjalizacja czy lokacja

ExpertStatus – typ wyliczeniowy reprezentujący aktualny status serwisanta.

Dostępne wartości ExpertStatus:

AVAILABLE, IN_PROGRESS, BREAK, UNAVAILABLE.

Location – klasa zawierające informacje dotyczące położenia taki jak długość

i szerokość geograficzna.


29

b. projekt ClientProgram

Pominięte zostały klasy biblioteki Java API for Google geocoder v3.

Rysunek 16 - diagram klas projektu ClientProgram

Pakiet gui składa się z następujących klas:

LoginFrame – graficzny interfejs użytkownika służący do zalogowania

się do platformy. Po poprawnym podaniu adresu IP platformy, numeru portu i

nazwy użytkownika otwarta zostaje instancja klasy MyFrame.


30

MyFrame - graficzny interfejs użytkownika służący do wysyłania zleceń naprawy.

Formularze, które zawiera dotyczą treści zlecenia oraz adresu.

Pakiet system składa się z następujących klas:

AgentManager – klasa zarządzająca pojedynczą instancją klasy ClientAgent.

Ważniejsze pola i metody klasy:

- public static ClientAgent agent – referencja do agenta działającego w części

użytkownika.

- public static ClientAgent getAgent() – zwraca referencję do u agenta

użytkownika.

- public static void deleteAgent() – kończy działanie agenta użytkownika.

ClientAgent – implementacja agenta użytkownika / klienta serwisu.

JadeManager - klasa odpowiedzialna za tworzenie i zarządzanie dzielonymi

kontenerami, tworzeniem w nich i usuwaniem agentów oraz wszystkim

co związane z platformą JADE.


- private static String agentName – nazwa agenta użytkownika.

- public void startRuntime(String[] params) – uruchamia JADE runtime.

- public void killRuntime() – zatrzymuje JADE runtime.

- public void startAgent(String name) – tworzy nowego agenta klienta

w platformie.

- public static void deletaAllAgents() – zamyka wszystkich agentów

w systemie.

Main – klasa wejściowa projektu. Służy do jego uruchamiania.

SendOrderBehavior – zachowanie, wysyłające zlecenie do platformy.


31

c. projekt OrderManager

Rysunek 17 - diagram klas projektu OrderManager

Pakiet manager składa się z następujących klas:

DataOperations - klasa posiadająca funkcjonalności związane z danymi

otrzymanymi przez managera.


- public static void printExpert(ExpertData expert) – metoda wypisująca

informacje dotyczące podanego serwisanta.

MathOperations - klasa zawierające metody wyliczeniowe takie jak obliczanie

odległości między dwoma punktami.


- public static double calcDistance(double lat1, double lon1, double

lat2, double lon2) – metoda zwracająca odległość euklidesową w kilometrach.

- private static double deg2rad(double deg) – metoda zamieniająca miarę

łukową kąta płaskiego ze stopni na radiany.

OrderManagerAgent – główna klasa agenta managera wiadomości. Rozszerza

klasę Agent. Zawiera już w sobie zachowania w postaci klas anonimowych takie

jak odbieranie wiadomości (rozszerzające CyclicBehaviour) oraz cykliczną obsługę


32

zleceń, które nie zostały z jakiegoś powodu przekazane do serwisantów

(rozszerzające TickerBehaviour).


- private static final long REFRESH_TIME = 1 * 5 * 1000 – interwał czasowy

między próbami obsługi nieprzekazanych zleceń.

- ArrayList<Message> unhandledOrders – zbiór nieprzesłanych do serwisantów

zleceń.

- ArrayList<ExpertData> experts – zbiór serwisantów zarejestrowanych

w systemie.

- protected void removeExpert(ExpertData expert) – metoda usuwająca

serwisanta z kolekcji zarejestrowanych.

- protected void addExpert(ExpertData expert) – metoda dodająca serwisanta

do kolekcji zarejestrowanych.

- protected ExpertData findExpert(String category, Message msgMessage) –

metoda znajdującego najodpowiedniejszego eksperta dla danego zamówienia

z daną kategorią.

- protected void updateExpert(Message msgMessage) – metoda aktualizująca

informacje na temat danego serwisanta.

- protected String findCategory(Message msgMessage) – metoda służąca

do rozpoznania kategorii danego zlecenia.

- private void sendMessage(Message message, AID user) – metoda wysyłająca

wiadomość do podanego agenta.

- private void registerInYP() – metoda rejestrująca agenta w Yellow Pages jako

„Manager”.


33

d. projekt AndroidExpert

Diagram został podzielony na pakiety:

pakiet agent

Rysunek 18 - diagram klas pakietu agent

Pakiet agent składa się z następujących klas:

AgentManager – klasa zarządzająca pojedynczą instancją klasy ClientAgent.


- public static ExpertAgent agent – referencja do agenta działającego w części

serwisanta.

- public static ExpertAgent getAgent() – zwraca referencję do u agenta

serwisanta.


34

- public static void deleteAgent() – kończy działanie agenta serwisanta.

ExpertAgent – klasa rozszerzająca klasę Agent. Reprezentuje agenta serwisanta.


- private Context context – kontekst w którym działa agent.

- OrderListActivity activity – aktywność przedstawiająca zbiór zleceń.

- private ExpertData expert – informacje dotyczące serwisanta.

- public void sendRegistrationMessage() – metoda służąca do zarejestrowania

się u managera systemu.

- public void sendDeregistrationMessage() – metoda służąca

do wyrejestrowania się u managera systemu.

- public void sendMessage(final Message message) – metoda służąca

do wysłania wiadomości do managera systemu.

- public void sendMessage(final Message message) – metoda służąca

do wysłania wiadomości do managera systemu.

pakiet agent.behaviours

Rysunek 19 - diagram klas pakietu agent.behaviours

Pakiet agent.behaviours składa się z następujących klas:

ChangeStatusBehaviour – zachowanie rozszerzające klasę Behaviour,

zmieniające aktualny status serwisanta oraz przekazujące informację

o tym do managera platformy. Rozszerza klasę OneShotBehaviour.


35

ReceiveMessageBehaviour– zachowanie rozszerzające klasę Behaviour,

odpowiedzialne za przyjmowanie widomości, ich obsługę oraz wyświetlenie

notyfikacji informującej w interfejsie użytkownika.


- OrderListActivity activity – aktywność wyświetlająca zbiór przyjętych

zleceń.

- private void makeNotification(Message msgMessage) – metoda wyświetlająca

notyfikację w pasku powiadomień informującą o odebranym zleceniu.

SendExpertLocationPeriodicalyyBehavior– zachowanie rozszerzające klasę

Behaviour, odpowiedzialne za cykliczne wysyłanie wiadomości do managera

platformy posiadające informacje dotyczące aktualnego położenia serwisanta.

pakiet features

Rysunek 20 - diagram klas pakietu features


36

Pakiet features składa się z następujących klas:

LocatioService – klasa rozszerzająca klasę Service. Jest to serwis działający

tak długo jak serwisant jest zalogowany do platformy. Odpowiada za ciągłe

śledzenie zmiany położenia serwisanta przy pomocy sygnału GPS oraz

przekazywanie ewentualnych zmian do managera platformy.


- private static final long LOCATION_REFRESH_TIME – minimalny interwał

czasowy między zmianami położenia podany w milisekundach.

- private static final float LOCATION_REFRESH_DISTANCE – minimalna

odległość uznawana jako zmiana położenia podana w metrach.

- private final int TIME_PERIOD – czas między aktualizacjami przekazywanymi

do managera w milisekundach.

- private SendExpertLocationPeriodicallyBehaviour behaviour – zachowanie

pozwalające na wysłanie informacji na temat zmiany położenia do managera.

- LocationManager mLocationManager – instancja klasy dostarczającej dostęp

do systemowych serwisów zajmujących się lokalizacją. Serwisy te pozwalają

aplikacji na cykliczne aktualizacje lokalizacji geograficznej.

- private final LocationListener locationListener – interfejs obserwatora

odbierającego informacje o zmianie położenia od instancji klasy LocationManager.

Log – klasa służąca do wygodnego używania logów systemowych w celach

testowych.


37

pakiet gui

Rysunek 21 - diagram klas pakietu gui


38

Pakiet gui składa się z następujących klas:

ExpertApplication – klasa rozszerzająca klasę Application. Używana

doutrzymywania globalnego stanu aplikacji.

MainMenuActivity – klasa rozszerzająca klasę Activity. Zawiera najważniejsze

elementy potrzebne do zalogowania się do platformy.

OrderAdapter – klasa rozszerzająca klasę BaseAdapter. Implementacja adaptera

wyświetlającego listę zleceń w obiekcie typu ListView.


- ArrayList<Order> orders – kolekcja zleceń znajdujących się w adapterze.

OrderListActivity – klasa rozszerzająca klasę Activity. Służy do wyświetlenia

i obsługi podstawowych funkcjonalności związanych ze zleceniami otrzymanymi

od klientów.


- ArrayList<Order> orderList – kolekcja zleceń wyświetlanych w aktywności.

- public ExpertAgent expertAgent – referencja do agenta serwisanta

działającego w platformie z aktualnie używanego urządzenia.

- public static ListView listView – lista wyświetlająca zlecenia.

- public void addOrder(final Message msgMessage) – metoda dodająca

otrzymane w wiadomości zlecenie do kolekcji przy jednoczesnym uaktualnieniu

wyświetlanej listy.

- public void loadOrdersFromMemory() – metoda wczytująca otrzymane

wcześniej i zapisane w pamięci urządzenia zlecenia.

- public void saveOrdersOnMemory() – metoda zapisująca aktualnie posiadane

zlecenia do pamięci urządzenia.

- public void sortByStatus() – metoda sortująca zlecenia według ich statusów.

- public static ListView listView – lista wyświetlająca zlecenia.

SettingsActivity – klasa rozszerzająca klasę Activity. Służy do wprowadzenia

danych potrzebnych do znalezienia platformy JADE. Zawiera formularze


39

z adresem IP oraz portem do wypełnienia. Dane są zapisywane następnie

przy pomocy SharedPreferences w urządzeniu w celu ich przywrócenia po

ponownym uruchomieniu aplikacji.

5.3. Implementacja najważniejszych procesów

Poniżej przedstawiono fragmenty kodu kluczowe dla działania całego podsystemu

producenta.

a. obsługa funkcjonalności platformy JADE (wersja PC)

Najważniejsze rzeczy związane z zarządzaniem platformą JADE znajdują

się głównie w klasach JadeManager oraz AgentManager. Pewne funkcjonalności

związane ściślej z agentami i ich zachowaniami zostały również zaimplementowane

w pozostałych klasach.

Uruchomienie JADE Runtime:

public void startRuntime(String[] params) { MicroBoot.main(params); }

Logowanie agenta do platformy (na przykładzie agenta klienta):

public void startAgent(String name) { this.agentName = name; try { MicroRuntime.startAgent(agentName, "system.ClientAgent", null); } catch (Exception e) { System.out.println("Blad logowania"); } }

Zarejestrowanie agenta managera w Yellow Pages jako „Manager”:

private void registerInYP() { DFAgentDescription dfd = new DFAgentDescription(); dfd.setName(getAID()); ServiceDescription sd = new ServiceDescription(); sd.setName("Manager"); sd.setType("Manager"); dfd.addServices(sd);


40

try { DFService.register(this, dfd); } catch (FIPAException e) { e.printStackTrace();

} }

Wyrejestrowanie agenta managera z Yellow Pages:

private void deregisterFromYP() { try { DFService.deregister(this); } catch (FIPAException e) { e.printStackTrace(); } }

Wysyłanie wiadomości posiadającą zserializowaną instancję jakiejś klasy

za pośrednictwem JADE do innego agenta:

private void sendMessage(Message message, AID user) { ACLMessage msg = new ACLMessage(ACLMessage.INFORM); System.out.println(user.getLocalName()); msg.addReceiver(user); try { msg.setContentObject(message); } catch (IOException e) { e.printStackTrace(); } send(msg); }

b. odwrócony geocoding

Ważnym aspektem ułatwiającym sprawne użytkowanie programu przeznaczonego

dla klientów jest automatyczna zamiana podanego adresu przez klienta

na współrzędne geograficzne (z angielskiego reverse geocoding). Dzięki temu

nadawca wiadomości nie musi się martwić o wybór dokładnej lokalizacji na mapie

a system sam po podanym adresie namierzy jego lokalizację. Do tej konwersji

wykorzystano bibliotekę Java Api for Google geocoder v3 korzystającą

z dostarczonego przez Google API. Przykładowe użycie tej biblioteki wygląda

następująco:

final Geocoder geocoder = new Geocoder();


41

String address = "Kraków stańczyka 10"; GeocoderRequest geocoderRequest = new GeocoderRequestBuilder().setAddress(address ).setLanguage("pl").getGeocoderRequest(); try { GeocodeResponse geocoderResponse = geocoder.geocode(geocoderRequest); System.out.println(geocoderResponse); } catch (IOException e) { e.printStackTrace(); }

Jako rezultat otrzymujemy:

GeocodeResponse{status=OK, results=[GeocoderResult{types=[premise], formattedAddress='Stańczyka 10, 30-126 Kraków, Polska', addressComponents=[GeocoderAddressComponent{longName='10', shortName='10', types=[street_number]}, GeocoderAddressComponent{longName='Stańczyka', shortName='Stańczyka', types=[route]}, GeocoderAddressComponent{longName='Bronowice', shortName='Bronowice', types=[sublocality_level_1, sublocality, political]}, GeocoderAddressComponent{longName='Kraków', shortName='Kraków', types=[locality, political]}, GeocoderAddressComponent{longName='Kraków', shortName='Kraków', types=[administrative_area_level_2, political]}, GeocoderAddressComponent{longName='małopolskie', shortName='małopolskie', types=[administrative_area_level_1, political]}, GeocoderAddressComponent{longName='Polska', shortName='PL', types=[country, political]}, GeocoderAddressComponent{longName='30-126', shortName='30-126', types=[postal_code]}], geometry=GeocoderGeometry{location=LatLng{lat=50.07830620000001, lng=19.8934052}, locationType=ROOFTOP, viewport=LatLngBounds{southwest=LatLng{lat=50.0769571697085, lng=19.8920562197085}, northeast=LatLng{lat=50.0796551302915, lng=19.8947541802915}}, bounds=LatLngBounds{southwest=LatLng{lat=50.0781181, lng=19.8930028}, northeast=LatLng{lat=50.07849419999999, lng=19.8938076}}}, partialMatch=false}]}

W odpowiedzi znajdują się informację o szerokości i długości geograficznej, której

potrzebowaliśmy. Dane te zostały wyodrębnione i użyte w metodzie służącej

do wysyłania zlecenia do części centralnej w której wykorzystano wprowadzony

przez użytkownika adres. Kod tej metody wygląda następująco:

protected void sendOrder() { Order order = new Order(AgentManager.agent.getAID(), AgentManager.agent.getLocalName() + new Date().toString(), taText.getText()); final Geocoder geocoder = new Geocoder(); String address = epAdress.getText(); GeocoderRequest geocoderRequest = new GeocoderRequestBuilder() .setAddress(address).setLanguage("pl").getGeocoderRequest();


42

try { GeocodeResponse geocoderResponse = geocoder .geocode(geocoderRequest);

double latitude = geocoderResponse.getResults().get(0)

.getGeometry().getLocation().getLat().doubleValue(); double longitude = geocoderResponse.getResults().get(0) .getGeometry().getLocation().getLng().doubleValue(); order.setLocation(new Location(latitude, longitude)); if (order != null) AgentManager.getAgent().addBehaviour( new SendOrderBehaviour(order)); } catch (IOException e) { e.printStackTrace(); } }

c. rozpoznawanie kategorii wiadomości

Użytkownik wysyłający wiadomość do systemu nie musi wypełniać żadnych

formularzy związanych z wyborem kategorii czy tematyki zgłoszenia. Część

centralna czyli manager całego systemu automatycznie rozpoznaje tematykę

wiadomości na podstawie słów kluczowych. Kategorie są przechowywane w postaci

plików tekstowych w projekcie OrderManager w katalogu categories. Każda

kategoria to osobny plik tekstowy a nazwa pliku odpowiada nazwie kategorii.

W pliku zapisane są informacje dotyczące słów kluczowych danej kategorii.

Struktura takiego pliku wygląda następująco:

[liczba określająca wagę słowa] [znak odstępu] [słowo kluczowe]

[liczba określająca wagę słowa] [znak odstępu] [słowo kluczowe]

(…)

Przykładowy wygląd pliku z kategorią:

Rysunek 22 - przykładowy plik kategorii


43

Każde słowo kluczowe znajduje się w nowej linii. Słowa są punktowane od 1 do 3.

Punkty 1 i 2 sumują się przy każdym wystąpieniu danego słowa w tekście

by następnie wybraną została kategoria z największą liczbą uzyskanych punktów.

Wyjątkiem jest gdy w tekście wystąpi słowo z punktacją 3. Są to słowa

przesądzające o wyborze danej kategorii i w wypadku wystąpienia takiego słowa

dalsze sprawdzanie nie jest już kontynuowane. Zaimplementowany algorytm

wyszukiwania kategorii wygląda następująco:

protected String findCategory(Message msgMessage) throws FileNotFoundException { Order o = (Order) msgMessage; File folder = new File("categories"); File[] listOfFiles = folder.listFiles(); String actualCategory, winningCategory = null; int actualPoints = 0, winningPoints = 0; String text = o.getDescription(); if (text == null) return "none"; String[] words = text.split("\\s+"); List<String> wordsList = Arrays.asList(words); for (File file : listOfFiles) { Scanner scanner = new Scanner(file); actualCategory = FilenameUtils.removeExtension(file.getName()); actualPoints = 0; while (scanner.hasNext()) { int wage = scanner.nextInt(); String word = scanner.next(); for (String string : wordsList) { if (string.equals(word)) { switch (wage) { case 1: actualPoints += 1; break; case 2: actualPoints += 2; break; case 3: return actualCategory; } continue; } } } if (actualPoints > winningPoints) {


44

winningCategory = actualCategory; winningPoints = actualPoints; } scanner.close(); } return winningCategory; }

d. wybór najlepszego serwisanta dla danego zamówienia

Po tym jak manager rozpozna kategorie zlecenia musi on dokonać selekcji

najbardziej odpowiedniego dla tego zlecenia serwisanta. Korzystając z posiadanej

kolekcji obecnie działających serwisantów dokonuje selekcji tych, którzy zajmują

się daną kategorią i są obecnie dostępni. Jeżeli nie ma żadnych dostępnych

serwisantów w danej kategorii wyszukiwani są ci, którzy mają przerwę i kolejno ci,

którzy są zajęci. Z pośród wyselekcjonowanych serwisantów wybierany jest ten,

który znajduje się najbliżej lokalizacji otrzymanego zlecenia. Powyższy algorytm

prezentuje się następująco:

protected ExpertData findExpert(String category, Message msgMessage) { // szuka dostępnych ArrayList<ExpertData> expertsFound = new ArrayList<>(); for (ExpertData expert : experts) { if (expert.getStatus() == ExpertStatus.AVAILABLE

&& (expert.getCategory().equals(category) || category == null )) expertsFound.add(expert); } // jezeli nie ma dostępnych to szuka na przerwie if (experts.isEmpty()) for (ExpertData expert : experts) { if (expert.getStatus() == ExpertStatus.BREAK

&& (expert.getCategory().equals(category) || category == null ))

expertsFound.add(expert); } // jezeli nie ma dostępnych to szuka zajętych if (experts.isEmpty()) for (ExpertData expert : experts) { if (expert.getStatus() == ExpertStatus.IN_PROGRESS

&& (expert.getCategory().equals(category) || category == null ))

expertsFound.add(expert); } // jezeli nie ma nikogo zwraca null i dodaje wiadomośc do kolejki do // pozniejszego sprawdzenia: if (experts.isEmpty()) {


45

System.out.println("Brak dostępnych ekspertow na liście."); return null; } // szuka najblizszego - liczy odległości euklidesowe double winningDistance = Double.MAX_VALUE; ExpertData winningExpert = null; for (ExpertData expert : expertsFound) { double distance = MathOperations.calcDistance(msgMessage

.getLocation().getLatitude(), msgMessage.getLocation()

.getLongitude(), expert.getLocation().getLatitude(), expert .getLocation().getLongitude()); if (distance < winningDistance) { winningDistance = distance; winningExpert = expert; } } return winningExpert; }

Algorytm obliczania odległości między dwoma punktami:

public static double calcDistance(double lat1, double lon1, double lat2, double lon2) { double R = 6371; // promien ziemi [km] double dLat = deg2rad(lat2 - lat1); double dLon = deg2rad(lon2 - lon1); double a = Math.sin(dLat / 2) * Math.sin(dLat / 2) + Math.cos(deg2rad(lat1)) * Math.cos(deg2rad(lat2)) * Math.sin(dLon / 2) * Math.sin(dLon / 2); double c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); double d = R * c; return d; } private static double deg2rad(double deg) { return deg * (Math.PI / 180); }

W przypadku gdy nie zostanie odnaleziony żaden serwisant spełniające powyższe

kryteria, zlecenie zostanie dodane do kolekcji nieobsłużonych zleceń i zostanie

zakolejkowane do późniejszego, ponownego sprawdzenia. Sprawdzenie odbywa

się cyklicznie co pewien określony czas i zostało zaimplementowane w klasie

anonimowej rozszerzającej TickerBehaviour:

addBehaviour(new TickerBehaviour(this, REFRESH_TIME) { @Override protected void onTick() { System.out.println("----------------"); System.out.println("LISTA EKSPERTÓW:");


46

for (ExpertData expert : experts) { DataOperations.printExpert(expert); } System.out.println("----------------"); if (unhandledOrders.isEmpty()) { System.out.println("BRAK NIEOBSLUZONYCH ZLECEN"); return; } System.out.println("PONOWNE SZUKANIE DLA NIEOBSLUZONYCH ZLECEN - " + unhandledOrders.size()); ArrayList<Message> toDelete = new ArrayList<>(); for (Message order : unhandledOrders) { String category = null; try { category = findCategory(order); } catch (FileNotFoundException e) { e.printStackTrace(); } System.out.println("#category - "+category); ExpertData expert = findExpert(category, order); if (expert != null) { sendMessage(order, expert.getAid()); toDelete.add(order); } } for (Message message : toDelete) { unhandledOrders.remove(message); } System.out.println("\n"); } });

e. opracowanie części systemu przeznaczonej na system operacyjny Android

Kluczową rzeczą dla działania całego systemu było opracowanie części

przeznaczonej dla serwisantów przeznaczonej na system operacyjny Android oraz

wykorzystanie możliwości jakie dają urządzenia mobilne (smartfony i tablety).

Pomimo tego, że aplikacje działające w środowisku Android są napisane w całości

w języku JAVA, sam model aplikacji jest inny od standardowych programów

przeznaczonych na PC. Plikiem, który najlepiej opisuje całość aplikacji i jest

obligatoryjnym dla każdej aplikacji jest plik AndroidManifest.xml. W tym wypadku

prezentuje się on następująco:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mechanic.androidexpert" android:versionCode="1" android:versionName="1.0" >


47

<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <uses-permission android:name="android.permission.VIBRATE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" /> <uses-permission android:name="android.permission.WAKE_LOCK" /> <permission android:name="chat.client.gui.permission.MAPS_RECEIVE" android:protectionLevel="signature" /> <uses-feature android:glEsVersion="0x00020000" android:required="true" /> <uses-permission android:name="chat.client.gui.permission.MAPS_RECEIVE" /> <uses-permission android:name="com.google.android.providers.gsf.permission.READ_GSERVICES" /> <uses-feature android:name="android.hardware.camera" > </uses-feature> <uses-sdk android:minSdkVersion="11" android:targetSdkVersion="21" /> <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" > <service android:name="jade.android.MicroRuntimeService" /> <activity android:name="gui.LocationActivity" android:label="@string/app_title_main" > </activity> <activity android:name="gui.MainMenuActivity" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="gui.MapActivity" > </activity> <activity android:name="gui.SettingsActivity" android:label="@string/app_title_settings" > </activity> <activity android:name="gui.OrderListActivity" android:label="@string/app_title_chat" android:launchMode= "singleInstance"> </activity>


48

<service android:name="features.LocationService" android:label="@string/app_title_main" > </service> </application> </manifest>

Aby sprostać tym odmiennym wymaganiom została stworzona specjalna wersja

biblioteki JADE przeznaczona na ten system i jest określana jako JadeAndroid.

Ze względu na architekturę systemu Android czas uruchomieniowy JADE musi być

otoczony przez serwis. Bibliotek JadeAndroid posiada dwie klasy serwisowe:

jade.android.RuntimeService oraz jade.android.MicroRuntimeService. W tym

wypadku wykorzystana została klasa MicroRuntimeService. Jak można zobaczyć na

listingu powyżej, została ona zadeklarowana w pliku AndroidManifest.xml.

Pierwszą operacją potrzebną do aktywowania czasu uruchomieniowego JADE

z aktywności jest powiązanie tej aktywności z MicroRuntimeService. Jako rezultat

otrzymujemy obiekt klasy jade.android.MicroRuntimeServiceBinder który posłuży

do zarządzania operacjami JADE. Mając ten obiekt możemy uruchomić dzielony

kontener JADE w platformie (metoda statContainer()). Kiedy czas uruchomieniowy

jest aktywny możemy stworzyć w systemie agenta serwisanta (metoda statAgent())

Całość została wywołana w aktywności MainMenuActivity:

public void startListAct(final String nickname, final String host, final String port, final RuntimeCallback<AgentController> agentStartupCallback) { final Properties profile = new Properties(); profile.setProperty(Profile.MAIN_HOST, host); profile.setProperty(Profile.MAIN_PORT, port); profile.setProperty(Profile.MAIN, Boolean.FALSE.toString()); profile.setProperty(Profile.JVM, Profile.ANDROID); if (AndroidHelper.isEmulator()) { // Emulator: this is needed to work with emulated devices profile.setProperty(Profile.LOCAL_HOST, AndroidHelper.LOOPBACK); } else { profile.setProperty(Profile.LOCAL_HOST, AndroidHelper.getLocalIPAddress()); } // Emulator: this is not really needed on a real device profile.setProperty(Profile.LOCAL_PORT, "2000"); if (microRuntimeServiceBinder == null) { serviceConnection = new ServiceConnection() { public void onServiceConnected(ComponentName className, IBinder service) {


49

microRuntimeServiceBinder = (MicroRuntimeServiceBinder) service;

logger.log(Level.INFO, "Gateway successfully bound to MicroRuntimeService"); startContainer(nickname, profile, agentStartupCallback); }; public void onServiceDisconnected(ComponentName className) { microRuntimeServiceBinder = null; logger.log(Level.INFO, "Gateway unbound from MicroRuntimeService"); } }; logger.log(Level.INFO, "Binding Gateway to MicroRuntimeService..."); bindService(new Intent(getApplicationContext(), MicroRuntimeService.class), serviceConnection, Context.BIND_AUTO_CREATE); } else { logger.log(Level.INFO, "MicroRumtimeGateway already binded to service"); startContainer(nickname, profile, agentStartupCallback); } } private void startContainer(final String nickname, Properties profile, final RuntimeCallback<AgentController> agentStartupCallback) { if (!MicroRuntime.isRunning()) { microRuntimeServiceBinder.startAgentContainer(profile, new RuntimeCallback<Void>() { @Override public void onSuccess(Void thisIsNull) { logger.log(Level.INFO, "Successfully start of the container..."); startAgent(nickname, agentStartupCallback); } @Override public void onFailure(Throwable throwable) { logger.log(Level.SEVERE, "Failed to start the container..."); } }); } else { startAgent(nickname, agentStartupCallback); } } private void startAgent(final String nickname, final RuntimeCallback<AgentController> agentStartupCallback) { microRuntimeServiceBinder.startAgent(nickname, ExpertAgent.class.getName(), new Object[] { getApplicationContext() }, new RuntimeCallback<Void>() { @Override public void onSuccess(Void thisIsNull) { logger.log(Level.INFO, "Successfully start of the " + ExpertAgent.class.getName() + "...");


50

try { agentStartupCallback.onSuccess(MicroRuntime .getAgent(nickname)); } catch (ControllerException e) { agentStartupCallback.onFailure(e); } } @Override public void onFailure(Throwable throwable) { logger.log(Level.SEVERE, "Failed to start the " + ExpertAgent.class.getName() + "..."); agentStartupCallback.onFailure(throwable); } }); }

Istotną rzeczą dla działania całego systemu jest monitorowanie położenia

serwisantów. Możliwe jest to dzięki wykorzystaniu serwisów lokalizacyjnych

systemu Android. W aplikacji został zaimplementowany serwis wykorzysujący

właśnie te mechanizmy i aktualizujący położenie w zmiennych serwisanta, które

są następnie przekazywane do managera. W pierwszej kolejności zdefiniowano

listener, w którym określono działania podjęte po zmianie lokalizacji:

private final LocationListener locationListener = new LocationListener() { @Override public void onLocationChanged(final Location location) { System.out.println("location changed"); if (AgentManager.getAgent() == null || AgentManager.getAgent().getExpertData() == null) return; AgentManager .getAgent() .getExpertData() .setLocation( new structures.Location(location.getLatitude(), location.getLongitude())); } @Override public void onProviderDisabled(String provider) { System.out.println("onProviderEDiasbled"); } @Override public void onProviderEnabled(String provider) { System.out.println("onProviderEnabled"); } @Override

public void onStatusChanged(String provi, int stat, Bundle extr) { System.out.println("onStatusChanged");


51

}

};

Listener następnie jest wykorzystany w serwisie lokalizacyjnym. W tej aplikacji

lokalizacja jest określana na podstawie odczytu z wbudowanego w urządzenie

modułu GPS:

@Override public void onCreate() { behaviour = new SendExpertLocationPeriodicallyBehaviour( AgentManager.getAgent(), TIME_PERIOD); AgentManager.getAgent().addBehaviour(behaviour); mLocationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); mLocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,

LOCATION_REFRESH_TIME, LOCATION_REFRESH_DISTANCE, locationListener);

Location location = mLocationManager .getLastKnownLocation(LocationManager.GPS_PROVIDER); if (location != null) AgentManager .getAgent() .getExpertData() .setLocation( new structures.Location(location.getLatitude(), location.getLongitude())); super.onCreate(); }

W aplikacji zaimplementowano obsługę powiadomień informujących o otrzymanym

zlecenie. Funkcja ta znajduje się w zachowaniu ReceiveMessageBehaviour

i jest wywoływana po odebraniu wiadomości ze zleceniem:

private void makeNotification(Message msgMessage) { Uri uri= RingtoneManager.getDefaultUri(RingtoneManager.TYPE_NOTIFICATION); String title = ((Order)msgMessage).getTitle(); String text = ((Order)msgMessage).getLocation().getLatitude()+ " –

"+((Order)msgMessage).getLocation().getLongitude(); NotificationCompat.Builder builder = new Builder(activity) .setSmallIcon(R.drawable.order_notification).setContentTitle(title) .setContentText(text).setSound(uri).setAutoCancel(true); Intent resultIntent = new Intent(activity, OrderListActivity.class); PendingIntent resultPendingIntent = PendingIntent.getActivity( activity, 0, resultIntent, PendingIntent.FLAG_UPDATE_CURRENT);


52

builder.setContentIntent(resultPendingIntent);

NotificationManager notificationMgr = (NotificationManager) activity.getSystemService(Context.NOTIFICATION_SERVICE);

notificationMgr.notify(notificationId, builder.build()); notificationId++; }


53

6. Działanie programu

Poniżej zostały opisane główne funkcjonalności związane z użytkowaniem

kompletnego systemu.

Użytkownik logujący się jako klient musi wprowadzić adres IP platformy JADE,

swoją nazwę oraz numer portu (domyślnie 1099).

Rysunek 23 - okno logowania

Jeżeli logowanie nie powiedzie się aplikacja zostaje zamknięta. W przeciwnym

wypadku zostanie otworzone główne okno programu.

Rysunek 24 - główne okno klienta


54

Po zalogowaniu wyświetli się okno z formularzem zgłaszania problemu. Jak widać

jedyne co klient musi wypełnić to opis problemu oraz adres. Po przyciśnięciu przycisku

„SEND” wiadomość z tymi informacjami zostanie przekazana do części centralnej

i zostanie dalej przetworzona. Jeżeli wiadomość zostanie wysłana prawidłowo

otrzymamy informację:

Rysunek 25 - komunikat pomyślnego wysłania wiadomości

Manager wiadomości (część centralna systemu) cyklicznie wyświetla listę

dostępnych ekspertów oraz sprawdza nieobsłużone wcześniej zadania. Podczas tych

operacji wyświetlane są komunikaty w konsoli mające taką postać:

Rysunek 26 - przykładowe komunikaty managera

Jak widać przy każdym ekspercie zostają wyświetlone takie informacje jak jego

nickname, którego użył do logowania, specjalizacja, którą się zajmuje, aktualny status

oraz długość i szerokość geograficzna. W liście nieobsłużonych zleceń informacje

zostały ograniczone jedynie do kategorii. Wyświetlona jest również całkowita liczba

tych zleceń.


55

Każda otrzymana przez managera wiadomość jest identyfikowana dzięki zmiennej

mówiącej o jej typie oraz odpowiednio obsługiwana. Po otrzymaniu wiadomości

wyświetlana jest w konsoli odpowiednia wiadomość. Przykład:

Rysunek 27 - komunikat otrzymania wiadomości przez managera

Wszelkie informacje systemowe związane z platformą JADE i dostarczone przez

te bibliotekę wyświetlane są w konsoli w kolorze czerwonym przy pomocy czerwonego

tekstu. Przykład:

Rysunek 28 - komunikaty platformy JADE

Dodatkowo sama platforma może zostać otwarta wraz z dodatkowym, dostarczonym

przez bibliotekę interfejsem graficznym, który posiada wiele przydatnych opcji takich

jak na przykład dodawanie nowych agentów czy tez ich usuwanie.

Rysunek 29 - okno platformy JADE


56

Serwisant loguje się do platformy dzięki specjalnie dla niego dostarczonej wersji

aplikacji na urządzenia mobilne z systemem operacyjnym Android. Poniżej została

zaprezentowana wejściowa aktywność aplikacji, gdzie serwisant podaje swój nickname,

może przejść do konfiguracji a także zalogować się do platformy.

Rysunek 30 - główna aktywność serwisanta

Pierwszą czynnością, którą powinien podjąć serwisant powinno być wejście do zakładki

z ustawieniami w celu wprowadzenia używanego przez platformę adresu IP, portu oraz

wyboru dziedziny, w której się specjalizuje.

Rysunek 31 - aktywność z opcjami serwisanta


57

Podczas logowania zostaje wyświetlona wiadomość mówiąca o próbie podłączenie

się do platformy o wprowadzonym wcześniej adresie IP.

Rysunek 32 - komunikat łączenia się z platformą JADE

Po poprawnym zalogowaniu się do platformy aplikacja samoczynnie otworzy

aktywność wyświetlającą zlecenia otrzymane od klientów. Do aktywności będą

na bieżąco dodawane nowe zlecenia oraz automatycznie zostaną wczytane, te, które

zostały otrzymane w poprzednich sesjach korzystania z aplikacji.

Rysunek 33 - aktywność wyświetlająca zlecenia

Jest to również moment, w który rozpoczyna się monitorowanie aktualnego położenie

serwisanta na podstawie sygnału GPS. Wyświetlona zostaje specjalna notyfikacja

informująca o tym pracownika. Notyfikacja ta nie może zostać usunięta przez samego

użytkownika. Zostaje ona deaktywowana dopiero po tym jak swoje działanie kończy

serwis odpowiedzialny za lokalizację. Ma to miejsce podczas wylogowywania


58

się z platformy a więc po zamknięciu aktywności startowej. Po kliknięciu na notyfikację

użytkownik zostanie przekierowany do aktywności zawierającą listę zleceń.

Rysunek 34 - notyfikacja mówiąca o lokalizacji w pasku

Każde nowe zlecenie oznaczone jest kolorem zielonym. Po otrzymaniu nowej

wiadomości serwisant dostaje informację w postaci dźwiękowej, domyślnie ustawionej

dla urządzenia oraz notyfikacji zawierającej informację o u zleceniu. Jest to notyfikacja,

która może zostać usunięta przez serwisanta. Po kliknięciu na notyfikację użytkownik

zostanie przekierowany do aktywności zawierającą listę zleceń.

Rysunek 35 - notyfikacja mówiąca o wiadomości na ekranie blokady


59

Każde wyświetlone zlecenie posiada kontekstowe menu opcji, gdzie znajdują się takie

funkcjonalności jak podjęcie danego zlecenia (zlecenie zmienia kolor

na pomarańczowy) oraz oznaczenie go jako ukończone (zlecenie zmienia kolor

na czerwony). Znajdują się tam również dodatkowe funkcjonalności takie jak usunięcie

zlecenia z listy, wyświetlenie jego położenia, a także włączenie nawigacji do miejsca

wybranego zgłoszenia.

Rysunek 36 - dodatkowe gunkcjonalności związane z zamówieniami

System jest przeznaczony na rynki zagraniczne dlatego też całość interfejsów

jak i słowa kluczowe kategorii zostały napisane w języku angielskim. Dalsze

modyfikacje wszystkich podprogramów, w celu dodania kolejnych funkcjonalności,

nie powinny stanowić problemów nawet dla osoby nie pracującej przy tej wersji

ze względu na przejrzysty, pisany zgodnie z przyjętymi konwencjami kod.


60

7. Uwagi końcowe

Udało się pomyślnie zrealizować założone przy projektowaniu systemu

wymagania funkcjonalne. System sprawnie przekazuje wiadomości między

użytkownikami oraz w sposób inteligentny wybiera docelowego adresata zamówienia

analizując odległości między zleceniem a serwisantami, biorąc również pod uwagę

ich dostępność. Kolejnymi etapami rozwoju mogłoby być zwiększenie bezpieczeństwa

systemu oraz integracja z bazą danych. Więcej informacji dotyczących pracy (takich

jak kompletna implementacja programu, diagramy, plik apk gotowy do instalacji

na urządzenia mobilne) można odleźć na płycie CD oraz pod adresem:

http://mateuszkaflowski.pl/praca-magisterska.

http://mateuszkaflowski.pl/praca-magisterska


61

8. Bibliografia

[1] Android Tutorial [online] [dostęp 2 czerwca 2015]

http://www.javatpoint.com/android-tutorial

[2] Application Fundamentals [online] [dostęp 2 czerwca 2015]

http://developer.android.com/guide/components/fundamentals.html

[3] Bellifemine Fabio, Caire Giovanni, Greenwood Dominic, „Developing Multi-Agent

Systems with JADE”, 2004

[4] Caire Giovanni, Jade Programming for Beginners, 2009

[5] Conder Shane, Darce Lauren, "Android Wireless Application Development", 2010

[6] Kerner Sean M, "Is Android Really Open Source?" [online] [dostęp 2 czerwca 2015]

http://www.eweek.com/blogs/first-read/is-android-really-open-source.html

[7] Rouse Margaret, "Android Open Source Project (AOSP)", [online] [dostęp

2 czerwca 2015] http://searchconsumerization.techtarget.com/definition/Android-Open-

Source-Project-AOSP

[8] Vaughan-Nichols Steven, "Debunking four myths about Android, Google, and open-

source", [online] [dostęp 2 czerwca 2015] http://www.zdnet.com/article/debunking-

four-myths-about-android-google-and-open-source/

[9] Wiley John & Sons, “An Introduction to MultiAgent Systems”, 2002

[10] Wykłady z systemów inteligentnych agentów [online] [dostęp 19 grudnia 2014]

http://www.ii.uni.wroc.pl/~lipinski/pl/mas.php

Wykorzystane biblioteki:

JADE - http://jade.tilab.com/ [dostęp 15.01.2015]

Java API for Google geocoder v3 - https://code.google.com/p/geocoder-java/ [dostęp

15.01.2015]

Zawartość CD

Praca dyplomowa w postaci źródłowej (doc)

Praca dyplomowa w postaci pliku PDF

Kod źródłowy

http://www.javatpoint.com/android-tutorial

http://developer.android.com/guide/components/fundamentals.html

http://www.eweek.com/blogs/first-read/is-android-really-open-source.html

http://searchconsumerization.techtarget.com/definition/Android-Open-Source-Project-AOSP

http://searchconsumerization.techtarget.com/definition/Android-Open-Source-Project-AOSP

http://www.zdnet.com/article/debunking-four-myths-about-android-google-and-open-source/

http://www.zdnet.com/article/debunking-four-myths-about-android-google-and-open-source/

http://www.ii.uni.wroc.pl/~lipinski/pl/mas.php

http://jade.tilab.com/

https://code.google.com/p/geocoder-java/


62

Spis rysunków:

Rysunek 1 – główne elementy architektury [3] ........................................................................................... 9

Rysunek 2 - relacje między głównymi elementami architektury [3] ............................................................ 9

Rysunek 3 - paradygmat asynchronicznego przekazywania wiadomości w JADE [10] .............................. 10

Rysunek 4 - cykl życia Activity [1] ............................................................................................................... 12

Rysunek 5 - cykl życia Service [1] ............................................................................................................... 13

Rysunek 6 - diagram przypadków użycia ................................................................................................... 17

Rysunek 7 - diagram klas modułu komunikacji .......................................................................................... 19

Rysunek 8 - diagram aktywności z wysyłaniem zlecenia ........................................................................... 20

Rysunek 9 - diagram aktywności z monitorowaniem serwisanta .............................................................. 21

Rysunek 10 - diagram wdrożenia ............................................................................................................... 22

Rysunek 11 - pakiety projektu CommonSource ......................................................................................... 24

Rysunek 12 - pakiety projektu ClientProgram ........................................................................................... 25

Rysunek 13 - pakiety projektu OrderManager........................................................................................... 25

Rysunek 14 - pakiety projektu AndroidExpert ........................................................................................... 26

Rysunek 15 - diagram klas projektu CommonSource ................................................................................ 27

Rysunek 16 - diagram klas projektu ClientProgram ................................................................................... 29

Rysunek 17 - diagram klas projektu OrderManager .................................................................................. 31

Rysunek 18 - diagram klas pakietu agent .................................................................................................. 33

Rysunek 19 - diagram klas pakietu agent.behaviours ................................................................................ 34

Rysunek 20 - diagram klas pakietu features .............................................................................................. 35

Rysunek 21 - diagram klas pakietu gui ....................................................................................................... 37

Rysunek 22 - przykładowy plik kategorii .................................................................................................... 42

Rysunek 23 - okno logowania .................................................................................................................... 53

Rysunek 24 - główne okno klienta ............................................................................................................. 53

Rysunek 25 - komunikat pomyślnego wysłania wiadomości ..................................................................... 54

Rysunek 26 - przykładowe komunikaty managera .................................................................................... 54

Rysunek 27 - komunikat otrzymania wiadomości przez managera ........................................................... 55

Rysunek 28 - komunikaty platformy JADE ................................................................................................. 55

Rysunek 29 - okno platformy JADE ............................................................................................................ 55

Rysunek 30 - główna aktywność serwisanta .............................................................................................. 56

Rysunek 31 - aktywność z opcjami serwisanta .......................................................................................... 56

Rysunek 32 - komunikat łączenia się z platformą JADE ............................................................................. 57

Rysunek 33 - aktywność wyświetlająca zlecenia ....................................................................................... 57

Rysunek 34 - notyfikacja mówiąca o lokalizacji w pasku ........................................................................... 58

Rysunek 35 - notyfikacja mówiąca o wiadomości na ekranie blokady ...................................................... 58

Rysunek 36 - dodatkowe gunkcjonalności związane z zamówieniami ...................................................... 59

praca magisterska · open handset alliance (oha). celem oha jest wspieranie rozwoju otwartych...

Documents