Streszczenie: W artykule opisano zastosowanie obiektowych metod modelowania i notacji UML do opisu systemów agentowo-zorientowanych. Pokazano, że systemy agentowe różnią się od obiektowych założeniem, że system o agentowej architekturze zakłada autonomiczność obiektów, stanowiących komponenty z jakich system jest zbudowany. W typowych obiektowych architekturach obiekty nie są autonomiczne, sekwencje ich współpracy są z góry ustalone. System agentowo-zorientowany zakłada, że reakcja systemu jest tworzona dynamicznie jako efekt zachowania komponentów jakimi są autonomiczne agenty. Zdaniem autora systemy agentowe od obiektowych różni tylko to założenie. Warto jednak zwrócić uwaga na to, że tak zwane ‘systemy uczące się’ to raczej systemy agentowo-zorientowane.

Wprowadzenie

Cztery lata temu (2016) podejmowałem pierwsze próby modelowania systemów społecznych, oparte na ogólnej teorii systemów i pomyśle modelowania elementarnych komórek jako samodzielnych bytów, rozumianych każda jako odrębny “elementarny system”.

Model ten będzie uży­wa­ny prze­ze mnie w tek­stach na tema­ty spo­łecz­ne, w szcze­gól­no­ści te o dzia­ła­niu Państwa. Z racji tego, że to tylko hipo­te­za, kolej­ne tego typu arty­ku­ły i bada­nia będą sta­no­wi­ły testy tego mode­lu. Będę wdzięcz­ny za wszel­kie uwa­gi i przy­kła­dy oba­la­ją­ce tę tezę. (System społeczny – metody analizy i modelowania, 2016)

Od tamtego czasu minęło troszkę czasu, a z uwagi na to, że coraz częściej biorę udział w projektach z obszaru produkcji oraz jej automatyzacji, pojęcie elementarnego systemu stale wraca. Studia literaturowe pokazały, że obszary badań nad modelami systemów społecznych i badań nad projektowaniem samodzielnych systemów w inżynierii oprogramowania (np. Internet Rzeczy, ang. Internet of Things: IoT), spotkały już prawe 20 lat temu jako “systemy agentowe” (te mają historię sięgającą lat 80-tych ). Obecnie najczęściej jest chyba stosowane pojęcie Agent-Based Models (ABM) . Opierając się na wybranych ww. pracach pokażę jak mój model z roku 2016, ewoluował do tych stosowanych w obszarze ABM.

Rok temu opisywałem metodę modelowania dowolnego systemu z użyciem UML. Próby tego rodzaju są od lat podejmowane jednak idą w stronę budowy frameworków , ja zaś staram się zbudować metamodel jako metodę i narzędzie uniwersalne, możliwe do stosowania już na pierwszych, bardziej abstrakcyjnych, etapach analiz i projektowania.

Agenty i ich modele spotykane w literaturze

Jedna z najczęściej przytaczanych definicji agenta to:

??An agent is a computer system, situated in some environment, that is capable of flexible autonomous action in order to meet its design objectives.?? (Agent to system komputerowy [lub program] umieszczony w określonym środowisku, który jest zdolny do elastycznego, autonomicznego działania, aby zrealizować cele, dla których został stworzony.)

(nazwa ‘agenty’ jest powszechnie stosowane, zamiast słowa ‘agenci’, dla odróżnienia tego pojęcia od tego stosowanego w stosunku do ludzi będących ‘czyimś agentem’).

Prosty model agenta podaje w swojej pracy poglądowej Chen:

Powyższy model pokazuje agenta jako określony zbiór cech. Ten model nie pokazuje jednak mechanizmu działania agenta. Stanowi sobą raczej graficzną, realną definicję agenta. W tej samej publikacji autor prezentuje rozbudowany inny model:

W tym przypadku mamy już do czynienia z frameworkiem, czyli zestawem sklasyfikowanych elementów (biblioteki). Moim zdaniem jest to już propozycja implementacji (o czym pisze także autor, polecam lekturę całej publikacji). Podałem te dwa modele jako przykłady skrajnych pomysłów: pierwszy do tylko graficzna definicja, drugi to propozycja implementacji.

Ciekawą propozycję modelowania podali autorzy publikacji “Agent-Based Enhancement of Legacy Manufacturing Planning and Control Processes” . Poniżej model (diagram sekwencji UML, ) pokazujący scenariusz realizacji zamówienia przez zbiór agentów:

Agenty powyższego diagramu zostały zdefiniowane na odrębnym modelu, który autorzy przedstawili jako ontologię (polecam źródło). Nie przytaczam tu tego modelu, bo uważam, że ontologia (nawet wyrażona jako model UML) nie jest architekturą a modelem pojęciowym, o czym niedawno pisałem . Jednak powyższy diagram sekwencji oddaje ideę agentów jako elementów nadrzędnego systemu (system systemów).

Moja propozycja sytuuje się gdzieś po środku.

Agent jako autonomiczny system elementarny

Ogólny model systemu

W pracy autora Ogólnej Teorii Systemów , opisano prosty system ze sprzężeniem jako ogólny model systemu (dzisiaj można powiedzieć metamodel systemu):

Sekwencja opisująca reakcję powyższego modelu na bodziec ma następującą postać:

Tak to wygląda przy założeniu, że system to mechanizm ze sprzężeniem, czyli przyjmując cybernetyczny model systemu .

Cybernetyczny model w wersji analogowej jest łatwy do implementacji. Jeżeli mówimy o implementacji w postaci oprogramowania, czyli cyfrowej, potrzebny jest model opisany jako architektura aplikacji. Posłużę się obiektowym paradygmatem, który moim zdaniem jest najbardziej adekwatny w tym przypadku. Jeżeli przyjmiemy, że komputer to uniwersalny mechanizm (możliwe jest napisanie programu odwzorowującego określony system), zbudowany z procesora i pamięci, to powyższy scenariusz można idealizować do następującej postaci:

Idealizacja, jako metoda tworzenia uwiarygodnionych modeli, jest bardzo dobrym sposobem budowania abstrakcji dowolnego systemu, z czego w tej pracy także skorzystano.

Obiektowy model systemu

Oprogramowanie, jako ‘czarną skrzynkę’, opisuje sie w notacji UML z użyciem diagramu przypadków użycia, tu przedstawiono hipotetyczny system reagujący na dwa określone bodźce:

Przywołując przytoczoną już tezę, że komputer – jako procesor i pamięć – to uniwersalny mechanizm, architektura dowolnego ‘systemu’ może zostać zobrazowana jak poniżej:

Ten diagram, od wcześniejszego (Scenariusz z jednym blokiem jako blokiem sterującym), różni się zastosowanym wzorcem. W tym przypadku zastosowano zasadę hermetyzacji, to znaczy komponent, który żąda usługi od innego, nie ma dostępu do wiedzy o tym jak ta usługa jest realizowana (‘nie wie nic o jego wnętrzu’).

Można to pokazać, ‘odsłaniając’ kolejne ‘warstwy’ aplikacji:

Z perspektywy otoczenia system jest ‘czarną skrzynką’:

Ujawniając to, że system ma interfejs (opisany na modelu sprzężenia zwrotnego jako ‘sensor’ i ‘efector’ pokażemy interfejs i komponent realizujący logikę: ‘mechanism’:

Widać tu, że Interfejs nie “widzi” pamięci za “mechanizmem”, bo nie musi z niej korzystać, więc wiedzieć o jej istnieniu też nie musi. Pełny model i diagram sekwencji, obrazujący powstanie odpowiedzi na bodziec wygląda następująco:

Warto tu zwrócić uwagę, że pojęcie klasyfikatora w UML, jako elementu mającego określone cechy, czyli atrybuty i operacje, to nic innego jak elementarny system:

Takie pokazanie systemu jednak wyjawia jego wewnętrzną strukturę i niepotrzebnie (zbyt wcześnie) sugeruje implementację i związki z obiektowymi językami. Dlatego na etapie analiz systemowych znacznie wygodniej i bezpieczniej jest korzystać z klasyfikatorów strukturalnych czyli diagramów struktur złożonych UML lub diagramów komponentów. Poniżej ten drugi:

Po lewej stronie system jako czarna skrzynka, po prawej jego wewnętrzna struktura oparta na wcześniejszym założeniu, mówiącym że zachowanie systemu jest modelowane jako mechanizm i pamięć. Tu pokazano także, że znane z UML, interfejs wymagany i oferowany to odpowiednio: efektor i sensor (patrz wyżej: model cybernetyczny).

Swego czasu, na pewnym seminarium naukowym, spotkałem się z tezą pewnego prelegenta z tytułem naukowym, że w UML nie można zobrazować wejścia i wyjścia systemu. Jest to niestety dość często powtarzana teza i jak widać, nieprawdziwa.

Podsumowanie

Powyższy model pokazuje klasy komponentów (mechanizm i pamięć), to znaczy, że konkretny system może być złożony z wielu typów ‘mechanizmów’ i ‘pamięci’. W konsekwencji pokazany na początku framework może zostać z powodzeniem zobrazowany metodą jak powyżej, a konkretny pomysł na budowę agenta (framework) można wyrazić w postaci określonej konkretnej architektury.

Tak więc agentowo-zorientowane modele systemów z powodzeniem można modelować jako systemy obiektowe, uznając jedynie, że agent to autonomiczny komponent, a każdy system potencjalnie jest systemem systemów . Dlatego cytowany na początku diagram sekwencji, opisujący obsługę zamówienia , to nic innego jak obiektowy model systemu systemów. Przyjęcie agentowego podejścia (paradygmatu?) narzuca założenie o autonomii elementarnych systemów oraz istnienie określonego, zapewniającego komunikację agentów, środowiska. Rolę taką może pełnić np. tak zwana ‘szyna integracyjna’ (szyna ESB, ang. Enterprise Service Bus) . Dlatego opisane tu podejście z powodzeniem stosuję do projektowania architektury systemów IT u moich klientów.

Nowe jest to, że zamiast sztywnej architektury integracji i implementacji skończonej liczby, z góry określonych, procesów i sekwencji, w podejściu agentowym (ABM) możliwe stają się próby budowania zintegrowanych systemów “samouczących się”, złożonych z dedykowanych dziedzinowych produktów (aplikacje), niewymagających każdorazowej ingerencji człowieka dla każdego nowego bodźca z zewnątrz. Takie pojęcia jak machine learning czyli uczenie maszynowe czy neural networks czyli sieci neuronowe, to znane mechanizmy, jednak dostępne coraz większe mcde obliczeniowe dają nam nowe możliwości, w szczególności prace takich systemów w “czasie rzeczywistym”.

Dalsze prace

Obecnie autor pracuje nad opracowaniem modelu pojęciowego i metamodelu, który posłuży do uogólnienia efektów uzyskanych przez autorów cytowanych publikacji, skupiając się na samej teorii, opisującej kolejne systemy agentowe (paradygmat agentowy?) wdrażane i opisywane przez ich autorów. Autor pracuje nad wzorcem projektowym pokazującym granicę pomiędzy tradycyjna architekturą obiektową a agentową.

Przykładową strukturą systemu pokazano na poniższym diagramie. Można powiedzieć, że granica pomiędzy klasycznym modelem obiektowym a agentowym, wyraża się z postaci ‘reguły OR’. Innymi słowy, jeżeli scenariusz wykorzystania komponentów 2 i 3 przez przez ‘komponent 1’ jest z góry narzucony w implementacji, jest to klasyczny system obiektowy. Jeżeli scenariusz ten jest wynikiem aktualnego bodźca, historii komponentu 1 i stanu otoczenia, oraz dopuszczamy możliwość, by identyczny bodziec uruchomił różne scenariusze, jest to system agentowy. Problem w zdefiniowaniu granicy między tymi definicjami polega na określeniu granicy determinizmu ‘decyzji’ podejmowanej przez komponent 1.

Źródła