Prírodou inšpirované algoritmy

študijné materiály pre projekt mobilnej triedy umelej inteligencie

Späť ku kurzom triedy
Obsah
Základné princípy OOP
Prvý program v Objective C
Spoločný život dvoch objektov
Používanie Swarmu
Viac agentov v prostredí
Parametre modelu
Grafické rozhranie



Ostatné kapitoly
Swarm
RePast
LEM
SDML
Eos
DDLab


Tutoriály
 Celulárne automaty
 Morfogenéza
 Simulátory
 Evolučné algoritmy
 Chaos
 Roboty
 Rôzne


Grafické rozhranie

Doteraz boli možnosti sledovania našej simulácie alebo experimentu na nízkej úrovni. Teraz sa pokúsime o grafické zobrazenie života chrobákov a o zobrazovanie ich parametrov.
Ďalšou zmenou je, že máme hierarchiu vnorených Swarmov. Objekty môžu zapuzdrovať iné objekty a Swarmy iné Swarmy. ObserverSwarm vykoná vytvárania ModelSwarmu vo svojom vnútri. S vnorenou hierarchiou Swarmov máme tiež vnorené hierarchie vykonávania modelov a vo všeobecnosti, Swarmy môžu byť vnorené do týchto hierarchii ľubovolne hlboko. ObserverSwarm preberá zodpovednosť za vytváranie a riadenie ModelSwarmu a poskytuje množstvo ciest na pôsobenie na model a jeho sledovanie.

Štruktúra súboru main.m pre ObserverSwarm

Teraz vytvoríme nový druh Swarmu. ObserverSwarm bude GUISwarm, to znamená, že bude vedieť komunikovať s užívateľom cez obrazovku. Poskytuje tlačítkové ovládanie procesov funkciami go, stop, step, quit.

ObserverSwarm.m a ObserverSwarm.h

Funkciou ObserverSwarmu je pozorovanie ModelSwarmu. Preto postavíme viac grafických nástrojov. Množstvo z týchto vizualizačných nástrojov je veľmi všeobecných, čiže môžu byť použité na vizualizáciu v rôznych prípadoch. Znovu máme tri základné metódy: buildObject, buildActions a activateIn, takto to býva vo väčšine Swarmov. Swarmy sú súbormi objektov s rozvrhmi udalostí. V buildObject musíme najprv postaviť ModelSwarm tak ako pred tým v main.m, aj keď potrebuje vytvoriť novú Zónu.

Zóny sú objektmi, ktoré v Swarme riadia alokáciu a správu pamäte. V podstate sú Swarmy podtriedami zón, takže Swarm je v skutočnosti druh správcu pamäte, čím sa odlišuje od správcu činností (activity manager). So zónami môžeme zrušiť všetko čo sme predtým vytvorili bez toho aby sme sa odvolávali na metódu dropObject, ktorá ruší všetko čo sme postavili v buildObject.

Po tom ako užívateľ stlačí go pošleme správu ModelSwarmu aby vytvoril objekty. Toto je dôležité, pretože objekty v ModelSwarm musia existovať skôr ako ich začneme sledovať.

Najprv vytvoríme škálu farieb, čiže zobrazenie hodnôt do farieb.

Vytvoríme objekt ZoomRaster, čo je okno na zobrazovanie 2D dát na obrazovke. Budeme v ňom zobrazovať FoodSpace a tiež chrobáky, takže musíme nakonfigurovať veľkosť okna na veľkosť sveta. Metódy často vracajú smerník, čo je dôsledok vnoreného posielania odkazov. Takže ak chceme získať naozajstný údaj, často sa musíme pýtať na smerník.

Value2dDisplay je objekt ktorý konvertuje medzi 2D dátovými štruktúrami a RasterObjectom. Tento objekt riadi zobrazovanie FoodSpace.

Nakoniec máme Object2dDisplay, ktorý bude spravovať súbor objektov a zobrazovať ich na do príslušných častí okna.

V buildAction vytvoríme akcie potrebné pre simuláciu. Tu je postavený rozvrh (ale nie vykonávaný). Tento rozvrh môže byť považovaný za nezávislý od modelu, lebo niekedy je žiadúce, nechať bežať model bez zobrazovania.

Najprv necháme ModelSwarm vytvoriť rozvrhy. Potom vytvoríme ActionGrop pre odkazy, ktoré chceme posielať pozorovaným objektom. Rozvrhujeme správy pre obidvoch display manažérov požadujúc od nich zobrazovanie do rastra, a od rastra požadujeme jeho obnovovanie. Ďalej zariadime kontrolu vstupu od užívateľa (myš, klávesnica). Nakoniec znovu aktivujeme rozvrhy, ktoré sme postavili. Uvedomme si, že hoci hierarchické modely sú postavené zdola-nahor (objekty na vyššej úrovni potrebujú nižšie objekty) aktivácia sa prevádza zhora nadol. Všetky aktivity sú ovládané z najvyššej úrovne.

Zdrojové texty súborov:

Hore
Kontakt: Marek Bundzel