Informatyka Systemów Autonomicznych

Transkrypt

1 Rafał Jagielnicki, Wrocław, Informatyka Systemów Autonomicznych Bot informacyjny w sieci IM jako agent realizacja 1. Wstęp Celem pracy jest zaprezentowanie przykładowej realizacji funkcjonalności agenta programowego na podstawie istniejącego oprogramowania bota informacyjnego dla sieci IM (Instant Messaging), który został napisany na potrzeby pewnej istniejącej firmy. 2. Bot informacyjny Głównym motywem do stworzenia bota była chęć udostępnienia użytkownikom istniejącego już systemu bazodanowego tej firmy, dostępu do zgromadzonych w nim informacji za pośrednictwem rozmów w sieciach IM. Funkcjonalność bota obejmuje: automatyczne powiadamianie użytkownika o wystąpieniu wybranych zdarzeń (zdarzenie to określona zmiana w bazie danych, np. modyfikacja tabeli); każdy użytkownik sam decyduje o czym i kiedy chce być powiadamiany możliwość rozmowy z botem, podczas której, użytkownik może zapytać się o pewne informacje, które są pobierane z bazy danych systemu 3. Bot informacyjny jako agent Opisywane oprogramowanie posiada kilka cech agenta: obserwuje swoje otoczenie (otoczenie jakim jest baza danych i sieci komunikatorów internetowych) i pobiera z niego wybrane informacje reaguje na zmiany w otoczeniu i oddziaływuje na nie działa przez bardzo długi okres czasu (w pewnym sensie żyje) i jest ciągle aktywny (nawet jeżeli nic nie robi z punktu widzenia użytkownika) jest w pewnym stopniu autonomiczny i adaptacyjny

2 Wymienione cechy bota agenta są opisane dokładniej w pracy Bartosza Owczarka. 4. Realizacja funkcjonalności agenta Język implementacji to C# (środowisko.net), jednak przedstawione tutaj rozwiązania można zaprogramować w praktycznie dowolnym innym języku. Rys. 2. Schemat wielowątkowości programu Najbardziej istotną cechą jest tutaj silna wielowątkowość. Na powyższym schemacie widać, że główne wątki odpowiadające za ciągłe działanie bota (za jego życie i aktywność) to: wątek nasłuchujący sieci IM wątek monitorujący bazę danych Obydwa działają na zasadzie nieskończonej pętli, w której w każdym kroku są usypiane na pewien krótki okres czasu. Wykrywanie zmian otoczenia jest zrealizowane w każdym z nich inaczej: w wątku obsługi sieci IM użyte są mechanizmy języka C# (Events), które pozwalają wykonywać dowolne funkcje w momencie wystąpienia zdefiniowanego przez użytkownika zdarzenia; w tym przypadku zdarzenia pochodzą z bibliotek obsługujących poszczególne protokoły IM (Gadu Gadu, Skype itd.) i są to: nadeszła nowa wiadomośc, wysłano wiadomość, rozłączono itp.

3 w wątku obsługi bazy danych tutaj wątek sam monitoruje tabele, które zostały wybrane przez użytkownika i sprawdza, czy zmieniła się liczba wierszy lub ich zawartość; sprawdzanie zmian jest zrealizowane przez proste buforowanie poprzedniego stanu monitorowanej tabeli (niekoniecznie całej); alternatywne rozwiązanie, to użycie mechanizmu dostępnego w Microsoft SQL Server (tzw. Query Notifications), który pozwala automatycznie powiadomiać aplikację w momencie wystąpienia określonych zmian w bazie danych Oddziaływanie na otoczenie odbywa się w wątkach tworzonych w momencie wystąpienia określonych zdarzeń (na rysunku: wątki rozmów i wątki obsługi zmian w bazie danych). Można wyróżnić kilka reakcji: rozpoczęcie nowej rozmowy stworzenie nowej Sesji (obiektu, który opisuje trwającą rozmowę i jest jej identyfikatorem) obsługa trwającej rozmowy do wysyłania wiadomości używane są standardowe funkcje z biblioteki danego protokołu IM zakończenie rozmowy jeżeli użytkownik wyrazi taką chęć, wysyłając słowo koniec lub jeżeli zostanie przekroczony ustalony czas, jaki minął od momentu otrzymaina ostatniej wiadomości użytkownika; usunięcie obiektu Sesja dla danej rozmowy powiadomienie o zmianie w bazie danych wysłanie pojedyńczej wiadomości do użytkownika, z czytelnym opisem zmiany, jaka zaszła (np. Dodano nową fakturę. Jej wartość to... ); jest to niezależne od tego, czy użytkownik rozmawia z botem, czy nie Następne dwie cechy agentowości: adaptacyjność i autonomiczność zostały tutaj zaimplementowane tylko częściowo. O szczątkowej adaptacyjności (czyli umiejętności dostosowania się do zmieniających się warunków) może być tutaj mowa w kontekście sposobu prowadzenia przez bota rozmowy z użytkownikiem. Cała rozmowa ma postać menu i funkcji, które użytkownik może z niego wybierać. Funkcje mogą posiadać parametry, które albo podawane są przez użytkownika, albo pobierane z aktualnego kontekstu rozmowy. Przykład: menu kontrahenci Kategoria 'Kontrahenci': 1. Lista kontrahentów mających stronę WWW (kontrahenci www) 2. Lista kontrahentów mających adres (kontrahenci ) 2 Kontrahenci posiadający adres 1. POLCARD info@polcard.com.pl 2. LUKAS BANK info@lukas.com.pl 3. ABC info@abc.com.pl 4. TABIS office@tabis.pl

4 operacje 1. Pełna nazwa i adres kontrahenta (adres kontrahenta) adres kontrahenta 3 Adres kontrahenta: ABC Wrocław Polanka 12/6 Jak widać powyżej, użytkownik za pierwszym razem wybrał funkcję bez parametrów (podając jej numer z listy menu, czyli 2), za drugim razem wybrał funkcję podając jako parametr numer wiersza danych z aktualnego kontekstu (wybrał funkcję adres kontrahenta z parametrem 3, czyli trzecim elementem na liście kontrahentów (ABC) uzyskanej w wyniku wcześniej wybranej funkcji). Adaptacyjność bota polega tutaj na tym, że wszystkie możliwe do wykonania operacje (czyli funkcje do wyboru), dostepne dla nich parametry i kontekst danych za każdym razem mogą być inne. Bot w trakcie rozmowy dostosowuje się do użytkownika i pozwala mu wykonywać tylko takie operacje, które mają sens w danej chwili na bieżącym kontekście danych. Zostało to zrealizowane, poprzez definiowanie funkcji menu w plikach XML w takiej postaci, aby jasne było, jakiego typu wartości wejściowe i wyjściowe posiada dana funkcja. Dzięki temu można dynamicznie dopasowywać do siebie funkcje i dane (dane są określonego typu) w trakcie rozmowy, na podstawie właśnie tych typów. Przykładowy plik z definicją jednej z dostępnych funkcji (type wejściowe i wyjściowe zdefiniowane są w obrębie znaczników inputparameters i outputparameters, pozostałe znaczniki nie są istotne z punktu widzenia agentowości): <menuitem category="kontrahenci"> <name>nazwa_adres_kontrahent</name> <description>pełna nazwa i adres kontrahenta</description> <alias>adres kontrahenta</alias> <text>adres kontrahenta:</text> <query>select kh_symbol, adr_miejscowosc, adr_adres from kh Kontrahent inner join adr Ewid on kh_id = adr_idobiektu where adr_typadresu = 1 and kh_symbol = '${1}'</query> <helpmessage>wyświetla nazwę i adres wybranego kontrahenta. Należy podać symbol kontrahenta.</helpmessage> <inputparameters> <inputparameter index="1">kh_symbol</inputparameter> </inputparameters> <outputparameters> <outputparameter column="1">kh_symbol</outputparameter> <outputparameter column="2">adr_miejscowosc</outputparameter> </outputparameters> <permissions> </permissions> </menuitem>

5 Kolejna cecha, autonomiczność, pozwala agentowi na samodzielne inicjowanie działań. Jest ona obecna w opisywanym bocie również tylko częściowo i dotyczy powiadomień wysyłanych do użytkowników o zmianach w bazie danych. Bot przyjmuje od użytkowników informacje o czym i kiedy chcą być powiadamiani (realizują to odpowiednie funkcje w trakcie rozmowy, zapisywane podobnie jak w wyżej zamieszczonym pliku XML). Krótki przykład: powiadomienia Dostępne powiadomienia: 1. Adresy kontrahentów (wyłączone) 2. Aktualna lista towarów (wyłączone, ustaw parametry) włącz powiadomienie 2 Włączono powiadomienie o numerze 2 ustaw powiadomienie 2... ; następuje kilka pytań na temat żądanej ; częstotliwości otrzymywania informacji... ; i ewentualnych dodatkowych parametrów (tutaj np. ; maksymalna ilość towaru, typ towaru itd.) Od tej pory bot sprawdza co jakiś czas bazę danych dla użytkownika i ewentualnie wysyła mu wiadomość (tutaj z aktualną listą towarów). Można więc powiedzieć, że użytkownik deleguje bota agenta do przeglądania określonych tabel i przysyłania co jakiś czas informacji, które spełniają warunki podane przez użytkownika. Bot jednak sam uznaje, kiedy należy wysłać powiadomienie i robi to niezależnie od tego, czy trwa rozmowa z danym użytkownikiem, czy nie (wszystko wykonuje się w opisanym wcześniej wątku monitorującym bazę danych). 5. Wnioski Opisany bot informacyjny nie był projektowany z myślą o byciu agentem. To, że posiada on jednak kilka cech, które w mniejszym lub większym stopniu pozwalają określić go jako agenta programowego, osiągnięte zostało raczej nieświadomie. Opisana realizacja funkcjonalności tych cech powinna być traktowana jako przykład i z pewnością mogłaby być zaimplementowana inaczej/lepiej. Najbardziej oczywistym elementem do przyszłego udoskonalania jest sama rozmowa z botem, która ma postać funkcji wybieranych z menu. Można by pokusić się o próbę wprowadzanie rozmowy w języku naturalnym (albo chociaż zbliżonym do naturalnego), jednak jest to złożone zagadnienie (zwłaszcza dla języka polskiego), którego realizacja prawdopodobnie byłaby trudniejsza niż realizacja pozostałej funkcjonalności bota. Inną istotną cechą agenta, która

6 jest tutaj nieobecna, jest umiejętność zdobywania doświadczenia i wykorzystywania go w interakcji z użytkownikiem. W tym przypadku doświadczeniem mogłoby być zapamiętywanie najczęściej używanych przez każdego użytkownika funkcji i proponowanie mu skrótów, argumentów itd. Agent może też komunikować się z innym agentem. W przypadku bota informacyjnego polegałoby to na wymianie informacji z innym botem, za pośrednistwem sieci IM. W praktyce byłoby to po prostu wysyłanie wiadomości tekstowych przez dwa takie automaty (zamiast tekstu można wysyłać np. bardziej złożone obiekty, które zostały poddane serializacji, jednak medium to po prostu sieć danego komuniakatora). Przykładowe zastosowanie to np. wymiana informacji handlowych, zgromadzonych w dwóch różnych bazach danych, przez dwa różne boty, które znają wspólny protokół komunikacji. Inne cechy agenta wydają się nie mieć tutaj praktycznego zastosowania (mobilność, osobowość jedynie w przypadku rozmowy w języku naturalnym). Literatura [1] Kod źródłowy opisywanego oprogramowania [2] Materiały do wykładu (m.in. [3] [4]