Grafické rozhranieDoteraz 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 ModelSwarm u 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 ModelSwarm u 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 ObserverSwarm u je
pozorovanie ModelSwarm u. 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 ModelSwarm u 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 RasterObject om. 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:
|