Agentti-sovelluskehyksen soveltuvuus esimerkiksi

Itse asiassa tarkemmin katsoessani uudelleenmääriteltäviä luokkia oli sentään muutama lisää. Lisäinformaatiota löytyy tietenkin itse gradusta. Sovelluskehys koostuu osasovelluskehyksistä, joita on tässä tarkasteltu erikseen.

Tapahtumaohjauspalvelu

Tukee tapahtumaohjattua (event-based) ohjelmointia. Sallii ohjelmoijan määritellä tapahtumia kuvaavia luokkia sekä määritellä tapahtumille käsittelijöitä.

Uudelleenmääriteltäviä luokkia

Event
Mallintaa tapahtuman. Sisältää tapahtumaan liittyvän informaation. Tämän luokan olio välitetään tapahtuman käsittelijälle tapahtuman lauettua. Luokassa määritellään myös milloin tällainen tapahtuma on lauennut.
EventRequest
Tapahtumankäsittelijä ilmoittaa kiinnostuksensa tapahtumaan luomalla tämän luokan olion (vastaa rekisteröintiä). Täytyy uudelleenmääritellä koska eri tapahtumat vaativat rekisteröinnin yhteydessä erilaista tarkentavaa tietoa (esim tiedostokuvaaja tai signaalin numero).
EventReceiver
Tapahtumankäsittelijä tehdään luomalla tästä luokasta aliluokka, joka osaa käsitellä tapahtuman.

Suunnittelumalleja

Singleton
Tapahtumasilmukassa odottavaa Dispatcher-oliota pitää olla vain yksi kappale, ja siihen täytyy päästä käsiksi globaalisti.
Chain of Responsibilityn ja Factory Methodin yhdistelmä (tavallaan)
EventRequest-oliot (siis EventRequest-luokan tai sen aliluokan oliot) ovat listassa, ja kun jotain tapahtuu, käydään jokaiselta kysymässä onko "sen" tapahtuma lauennut. "Kyllä"-vastauksena annetaan tapahtumankäsittelijälle lähetettävä Event-olio, "ei" = NULL. Poikkeaa tavanomaisesta CoR:ista sikäli että useampi olio voi vastata myöntävästi, ja oliot itse eivät vie kyselyä eteenpäin.

Huomio: Suunnittelumallista voi olla useita, toisistaan vähän poikkeavia versioita. FREDissä pitäisi ilmeisesti olla mahdollisuus määritellä suunnittelumallille eri variaatioita.

Tilakoneet

Sovelluskehys on tarkoitettu tilakoneiden määrittelyyn. Tilakonetta, tilaa, rakenteista tilaa ja siirtymää vastaavat omat luokkansa. Sovelluskehyksen huonoin puoli on että se tullaan korvaamaan erillisellä tilakonekielellä (tehokkaampaa ja helppokäyttöisempää).

Uudelleenmääriteltäviä luokkia

State
Tila-luokassa määritellään tilalle enter- ja exit-toiminnot. Jokaiselle tilalle ei tarvitse tehdä omaa aliluokkaa, vain niille joiden enter- ja exit-toiminnot eroavat toisistaan.
NestedState
Rakenteinen tila. Jokaiselle rakenteiselle tilalle täytyy määritellä vastaava luokka jossa suoritetaan sen sisältämien tilojen luominen.
Transition
Siirtymä. Jokaiselle siirtymälle ei välttämättä tarvita uutta luokkaa, mutta jos siirtymään liittyvää toimintaa halutaan muuttaa, täytyy uusi luokka määritellä.

Suunnittelumalleja

Composite
Rakenteiset tilat on toteutettu Composite-suunnittelumallin avulla.
Chain of responsibility (tavallaan)
Jokaiseen tilaan on liitetty lista sen siirtymistä, ja tullutta tapahtumaa tarjotaan vuorollaan jokaiselle, kunnes jokin hyväksyy sen (kukaan ei hyväksy => virhekäsittely, tn. pelkkä tapahtuman sivuuttaminen)
State
Tilakone-luokka tietysti käyttää State-suunnittelumallia.

Tiedonsiirtopalvelu

Uudelleenmääriteltäviä luokkia

IXU eli tietoalkio
Eri tyyppisille tietoalkioille määritellään omat aliluokat jossa kuvataan kuinka tällainen tietoalkio haetaan verkosta. IXU:t voivat olla rakenteisia.

Suunnittelumalleja

Strategy
Tietoalkio määrittelee hakustrategian (ks. yllä).
Composite
Rakenteiset IXU:t käyttävät (mahdollisesti, ei vielä kiinnitetty) Composite-suunnittelumallia.

Välimuisti

Uudelleenmääriteltäviä luokkia

Metadata
Eri tyyppisillä välimuistialkioilla on erityyppistä metatietoa (tiedon pituus, talletusaika, tallettaja, jne). Koska tietoa käsitellään Metadata-olioiden avulla, täytyy Metadata-luokasta määritellä uusia aliluokkia eri tietoalkiotyypeille.

Suunnittelumalleja

-

Yhteenveto

Tilakonesovelluskehyksen mukaan ottaminen on kyseenalaista, sillä "lopullisessa tuotteessa" sitä ei ole. Ongelma on kuitenkin sinänsä mielenkiintoinen, ja väsäilen sitä varmaan vielä jonkin verran . Sen mukaan ottaminen ei kuitenkaan välttämättä ole järkevää, joten olen alla laittanut sulkuihin luvut jossa tilakonesovelluskehys on mukana.

Uudelleenmääritettäviä luokkia: 5 (8)

Suunnittelumalleja: 5 (6)

Kuten näkyy, sovelluskehys ei ole kovin laaja. Sen vuoksi olen edelleen sitä mieltä, että jokin laajempi sovelluskehys soveltuisi paremmin pääasialliseksi case studyksi. Tätä voisi tietysti käyttää myös.

Home - comments?