Ohjelmistoarkkitehtuurit 2006 Harjoitustyön loppudokumentti. Robottisota. Ryhmä: <numero> Heikki Suontausta

Transkriptio

1 Ohjelmistoarkkitehtuurit 2006 Harjoitustyön loppudokumentti Robottisota Ryhmä: <numero> Heikki Suontausta Päiväys:

2 1 Johdanto Harjoitustyön aiheena oli toteuttaa graafinen simulaatiokehys erilaisten simulaatioiden suorittamiseen. Tämän lisäksi toteutettiin simulaatiokehykselle erikoistus, joka mahdollistaa robottisota-pelin pelaamisen. Pelissä on tarkoituksena ohjelmoida robotille tekoäly ja kokeilla sen toimivuutta taistelusimulaatiossa muita vastaavia robotteja vastaan. 2 Vaatimukset järjestelmälle Simulaatiokehys käyttää valmiina annettua käyttöliittymäkirjastoa, joka puolestaan vaatii Eclipsen SWT-kirjaston (The Standard Widget Toolkit) toimiakseen. Tämä mahdollistaa sovelluksen käytön kaikilla alustoilla joille SWT ja Java ovat saatavilla. SWT:n ansiosta käyttöliittymä on luonnollisen näköinen kullakin alustalla. 2.1 Toiminnalliset vaatimukset Koko järjestelmän toiminnallisiin vaatimuksiin kuuluu luonnollisesti kaikki simulaatioiden ajamiseen liittyvä: Alkutilan asettelu Ajaminen Ajonaikaisen tilannekuvan näyttäminen Simulaatiokehyksen ja sen erikoistuksen välinen raja toiminnassa on vedetty siihen, että simulaatioille yhteiset toiminnot on toteutettu kehyksessä ja muu jää erikoistuksen huoleksi. Täten edellä mainitusta listasta simulaatiokehyksen vastuulla on alkutilan asettelu ja ajon aikaisen tilannekuvan näyttäminen, kun taas erikoistuksen vastuulle jää itse simulaation ajaminen. Esimerkkinä koko järjestelmän kattavasta toiminnasta olkoon seuraava käyttötapaus: Nimi: Suorittaja: Robottisotaerikoistuksen käyttö Loppukäyttäjä Käyttötapauksen kulku: 1. Käyttäjä käynnistää sovelluksen 2. Käyttäjä valitsee item-toolbar:sta haluamansa robotin yksi kerrallaan, ja sijoittaa sen taistelualueelle. Sijoitettuaan robotin, käyttäjä voi pyöräyttää robottia 30 asteen välein hiiren oikealla napilla. 3. Kun kaikki taisteluun osallistuvat robotit on sijoitettu alueelle, käyttäjä käynnistää taistelun painamalla simulation-toolbar:n painiketta play. 4. Simulaatio käynnistyy ja robotit aloittavat taistelun. 5. Simulaatio päättyy kun jäljellä on enää yksi robotti. 6. Käyttäjä sulkee sovelluksen 2/26

3 Poikkeukset: Simulaation ajamisen aikana kaksi tai useampi robottia ajautuu liian kauas toisistaan, jolloin tutka ei kanna riittävän pitkälle eikä niiden tekoälyyn ole ohjelmoitu tarkemmin muiden robottien etsimistä. Tästä on seurauksena ettei simulaatio tulisi koskaan päättymään. Tällöin käyttäjä voi pysäyttää simulaation painamalla simulation-toolbar:n painiketta stop. 2.2 Laatuvaatimukset Laatuvaatimukset jakautuvat tässä muunneltavuusvaatimuksiin ja suorituskykyvaatimuksiin. Muihin laadullisiin vaatimuksiin kuten saavutettavuuteen tai turvallisuuteen ei kiinnitetä sen enempää huomiota, koska kyseessä on yhden käyttäjän järjestelmä. Muunneltavuusvaatimukset simulaatiokehykselle ovat: Käyttöliittymään liittyvät Näkymien konfiguraatio mahdollisimman vapaata Oma työkalupalkki simulaation suorittamiselle Simulaatiomaailman koko, skaalaus Sovelluksen nimi Simulaatio-olioiden ulkoasu Simulaatio-olioiden tilan näyttö Toimintaan liittyvät Simuloinnin suoritus Erilaisia simulaatio-olioita Suorituskykyvaatimukset ovat: Vähintään 500 robottia mahdollista olla yhtä aikaa simulaatiossa Simulaation tulee reagoida nopeasti käyttäjän syötteeseen Muunneltavuusvaatimukset robottikehykselle ovat: Sovelluskohtaisen robotin luonti Sovelluskohtaisen robotin varustetyypin luonti Sovelluskohtaisen varusteen luonti Sovelluskohtainen engine esim. eri sääntöjä varten 3 Kehyksen arkkitehtuuri 3/26

4 3.1 Looginen näkymä Simulaatiokehyksen liittymistä käyttöliittymäkehykseen on havainnollistettu kuvassa 1. Observer rajapinnan toteuttavat simulaatiomaailmaa vastaava luokka SimulationWorld sekä yksittäistä simulaatio-oliota vastaava ItemModel. Nämä tiedottavat muutoksistaan käyttöliittymäkehykselle Observer rajapinnan välityksellä. WorldView käyttää maailman olioiden piirtoon ItemView:n toteuttamaa WorldViewItem rajapintaa. Tilanäkymä ItemStatus- View puolestaan käyttää StatusViewItem rajapintaa, jonka niin ikään ItemView toteuttaa. ItemModel käyttää rakentajassaan IdGeneratoria luomaan kullekin simulaatio-oliolle yksikäsitteisen Id-numeron. Tilanäkymä toteuttaa myös rajapinnan ActivationListener, jota käytetään tilanäkymässä olevien simulaatio-olioiden tietojen korostamiseen esim. valinnan yhteydessä. SimulationFactory on abstrakti kantaluokka, jonka toteutusten tehtävänä on luoda simulaatio-olioita sen createitem-funktion parametrina saadun luokan nimen perusteella. ItemController puolestaan on yhteinen rajapintaluokka kaikille kontrollereille. AbstractEngine:n perivä SimulationEngine on abstrakti kantaluokka kaikille erikoistusten engineille. Sen vastuulla on vain simulaation suorituksen hallinnointi (käynnistys, pysäytys yms.). SimulationToolbar on kehysten käyttämä käyttöliittymäkomponentti simulaation hallintaan. Lisäksi SimulationToolbar käyttää simulaatiomaailman koon muuttamiseen SizeDialog käyttöliittymäkomponenttia. SimulationToolbar:n käyttäminen on erikoistajan valinnan mukaista. Se on vain annettu valmiina toteutuksena ja se vaatii SimulationEngineInterface rapinnan toteutuksen erikoistajan enginessä. Kuvassa 1 esitetty myös robottikehyksen (RobotFW) liittyminen simulaatiokehykseen ja ajastimen osalta myös käyttöliittymäkehykseen. Robottikehyksen RobotM, joka perii simulaatiokehyksen ItemModel:n, edustaa yleistä robottien MVC arkkitehtuurimallin mukaista malliosaa. Vastaavasti simulaatiokehyksen ItemView rajapinnan toteuttava RobotV toteuttaa näkymäosan ja ItemController rajapinnan toteuttava RobotC kontrolleriosan. Robottien luonnista vastuussa on abstraktin SimulationFactory-luokan perivä RobotFactory, joka luo kontrolleriosan ja sen vastuulla puolestaan on robotin malli- ja näkymäosien luonti. Roboteilla on myös useita erilaisia varusteita, joita robottikehyksessä mallinnetaan Feature-luokalla, ja tästä perityillä abstrakteilla Armor, Motor, Gun ja Radar luokilla. Kukin Featureluokasta peritty yksittäistä varustelajia kuvaava abstrakti luokka määrittää mm. rajapinnan miten kyseistä varustelajia käytetään. Lisäksi tässä on mahdollista määrittää yleinen toteutus (esim. template method suunnittelumallin mukaisesti), jolloin erikoistetussa konkreettisessa varusteessa (esim. LightArmor) on mahdollista toteuttaa vain sopiva laskukaava vahingon laskemiseen. Varusteiden luonti tapahtuu AbstractFeatureFactory:n avulla, joka pitää erikoistaa erikoistuksessa luomaan kyseiseen erikoistukseen kuuluva varustekirjo. SimulationEnginen perivä RobotEngine, jonka vastuulla on robottisimulaatioiden hallinta. RoboTimer puolestaan huolehtii robottisimulaatioiden ajastustehtävistä. Robottikehykseen luuluvat vielä rajapinnat ShopAccount ja TurnCredit, sekä näiden toteutukset ShopAccountImpl ja TurnCreditImpl. Näiden tehtävänä on rajoittaa robotin varusteiden hankkimista ja yhden pelivuoron aikana tehtävää toimintaa. 4/26

5 Kuva 1: Simulaatiokehyksen liittyminen käyttöliittymäkehykseen ja robottikehyksen liittyminen simulaatiokehykseen Periaatteita: Simulaatiokehys huolehtii maailmasta ja siinä olevista simulaatio-item:eistä ja niiden sijainnista sekä asennosta maailmassa. 5/26

6 Erikoistajan huoleksi jää mallintaa item:eiden tarkempi malli, käyttäytyminen ja ulkoasu. Simulaation toiminnallisuuden saavuttamiseksi erikoistajan on erikoistettava ajastimesta sellainen joka tekee halutun toimenpiteen käyttäjän valitsemalla intervallilla. Varsinainen simulaation suoritus (esim. item:eiden vuorotus) kannattaa kuitenkin jättää erikoistetun sovelluksen moottorin huoleksi. Simulaatiokehyksen luokat ja rajapinnat: Luokka/rajapinta: SimulationWorld Vastuu: Vastaa simulaatioon osallistuvien simulaatio-olioiden hallinnasta Kuvaus: Sinällään jo toimiva toteutus että erikoistus ei ole välttämätöntä Muuntelu: Muuntelu tarpeen jos simulaatio-oliot tai engine tarvitsevat jotain lisätoiminnallisuutta. Luokka/rajapinta: ItemModel Vastuu: Yksittäisen simulaatio-olion MVC mallin mukainen malliosa Kuvaus: Sisältää perustoteutuksen simulaatio-oliosta, jonka oletetaan kaikkien simulaatioolioiden tarvitsevan. Toteutukseen kuuluu olion sijainti ja pyörähdyskulma maailmassa sekä yksikäsitteinen id. Lisäksi sijainnin ja pyörähdyskulman muutoksista ItemModel tiedottaa tarkkailija mallin mukaisille tarkkailijoilleen. Muuntelu: Muuntelu tapahtuu lisäämällä simulaatio-olion muu malliosan mukainen toteutus. Luokka/rajapinta: IdGenerator Vastuu: Yksikäsitteisten id-tunnusten generointi Kuvaus: Luo kokonaislukumuotoisia id-tunnuksia kasvavassa numerojärjestyksessä. Muuntelu: Ylikirjoittamalla tunnuksen luova metodi. Luokka/rajapinta: ItemView Vastuu: Tarvittava rajapinta simulaatio-olion näyttämiseen käyttöliittymäkehyksessä. Kuvaus: Perii sekä käyttöliittymäkehyksen simulaatiomaailman näkymän ItemView että tilanäkymän StatusViewItem rajapinnat. Muuntelu: Toteuttamalla rajapintafunktiot. Luokka/rajapinta: SimulationFactory Vastuu: Rajapinta simulaatio-olioiden luomiseen. Kuvaus: Tämän abstraktin luokan toteutusten tulee toteuttaa metodi simulaatio-olion luo- 6/26

7 miseen sen luokan nimen perusteella esim. Javan reflektiota käyttäen. Kantaluokka puolestaan toteuttaa metodin minkä tahansa pakkauksen luokkien listaamisen ajon aikana. Muuntelu: Toteuttamalla rajapintafunktio Luokka/rajapinta: ItemController Vastuu: Yhteinen rajapinta simulaatio-olioiden kontrollereille Kuvaus: Tässä vaiheessa toimii vain yhteisenä kantarajapintana eri kontrollereille. Ei siis sisällä yhtään funktiota. Muuntelu: Erikoistus lisää omat rajapintafunktionsa. Luokka/rajapinta: SimulationEngine Vastuu: Simulaation suorituksen hallinnointi Kuvaus: Perii käyttöliittymäkehyksen abstract enginen ja laajentaa sitä Muuntelu: Toteuttamalla puuttuvat abstraktit funktiot sovelluksen käyttöliittymän alustuksessa (käyttöliittymän muuntelu) sekä toteuttamalla simulaation suoritus ja sen hallinnointi. Robottikehyksen luokkien ja rajapintojen kuvaukset: Luokka: RobotM Vastuu: Robotin malli Kuvaus: Esittää yksittäisen robotin tilaa. Sisältää myös robotille asennetut varusteet (Feature:sta perityt suojat, moottorin yms.). Luokka: Feature Vastuu: Abstrakti kantaluokka robottien varusteille Kuvaus: Määrittelee yleisen varusteiden rajapinnan ja sisältää yhteisen toiminnan toteutuksen. Tästä perityissä luokissa on laajennettu Feature:n rajapintaa kuhunkin varusteeseen sopivaksi. Ja niistä on edelleen periytetty varsinaiset varusteet, joita kuvassa havainnollistetaan Basic -etuliitteellä. Luokka: RobotV Vastuu: Yksittäisen robotin ulkoasu Kuvaus: MVC mallin mukainen toteutus robotin ulkoasun määritykselle. Luokka: RobotC Vastuu: Robotin alustus ja toiminta 7/26

8 Kuvaus: Luo robotin malli ja näkymäosat ja huolehtii robotin toimenpiteistä vuoron aikana. Tästä perityille robotti-plugineille annetaan toteutettavaksi robotin varustaminen eri varusteilla ja robotin vuoron toimenpiteet. Luokka: RobotFactory Vastuu: Robottien luonti Kuvaus: Osaa listata minkä tahansa pakkauksen luokat Java:n hakemistorakenteen avulla ja luoda niistä reflektion avulla instansseja. Luotujen instanssien rakentajalle annetaan parametrina RobotEngine luokan olio siitä nimitys RobotFactory. Luokka: RobotEngine Vastuu: Simulaation pyöritys ja sovelluksen kulun hallinnointi Kuvaus: Sovelluksen moottori. Luokka: RoboTimer Vastuu: Ajastustehtävä Kuvaus: Määrittelee abstraktissa kantaluokassaan avonaiseksi määritellyn task()-funktion. Sen toteutus kutsuu RobotEngine:n timertick()-funktiota. Luokka: ShopAccount ja ShopAccountImpl Vastuu: Tilin rajapinta ja sen toteutus Kuvaus: Tätä rajapintaa ja sen toteuttavaa luokka paria käytetään robotin varustamisessa. Näitä käytetään rajoittamaan robotille hankittavia varusteita antamalla vain tietty määrä rahaa käyttöön. Robotin tekoälyntekijän käytössä on vain rajoitettu rajapinta, joten hän ei pysty tilin saldoa muuttamaan. Luokka: TurnCredit ja TurnCreditImpl Vastuu: Pelivuorolla tapahtuvien toimintojen rajoittaminen Kuvaus: Tätä rajapintaa ja sen toteuttavaa luokkaparia käytetään robotin pelivuoron aikana rajoittamaan robotin tekemiä toimintoja. Suunnittelumallit kehyksissä: Tarkkailija suunnittelumallin käyttöä simulaatio- ja käyttöliittymäkehysten yhteydessä on havainnollistettu kuvassa 2. Kuvassa oleva ItemModel toimii tarkkailtavana ja sille on rekisteröitynyt kaksi tarkkailijaa WorldView ja ItemStatusView. ItemModel:n ja kaikkien siitä periytettyjen luokkien vastuulla on tarkkailija-suunnittelumallin mukaisesti tiedottaa tarkkailijoilleen muutoksistaan Observer rajapinnan kautta. 8/26

9 Kuva 2: Tarkkailija suunnittelumalli Abstraktin tehtaan käyttöä robottikehyksessä on kuvattu kuvassa 3. Kuvassa olevat Feature-luokasta perityt Armor, Motor, Gun ja Radar ovat abstraktin tuotteen roolissa. Näistä pitää robottikehyksen erikoistajan luoda perinnän avulla konkreettiset tuotteet (ei kuvassa). On myös mahdollista, että robottikehyksen mukana tulee joistakin näistä oletustoteutus. AbstractFeatureFactory on puolestaan abstraktin tehtaan roolissa, ja siitäkin pitää erikoistajan tehdä oma toteutus jos erikoistaja on tehnyt myös omia tuotteita. Jos robottikehyksen mukana toimitetaan joistakin varusteista oletustoteutus, on myös mahdollista toimittaa tehtaastakin ns. oletustoteutus, joka osaa luoda näistä instanssit. Kuva 3: Abstrakti tehdas suunnittelumalli Operaatiorunko (engl. template method) suunnittelumallin käyttö robottikehyksessä on esitetty kuvassa 4. Tässä esimerkkinä on suojien tehon laskenta, jossa abstraktissa kantaluo- 9/26

10 kassa on toteutettu hit() -funktio käyttäen abstraktiksi määriteltyjä calculate alkuisia funktioita käyttäen. Näillä on tarkoituksena laskea paljonko kyseisestä osumasta aiheutuu vahinkoa itse suojalle, robotille ja muille varusteille. Selkeyden vuoksi kuvasta on jätetty pois kuinka calculate -funktioiden paluuarvoja käytetään hit()-funktiossa. Operaatiorunko suunnittelumallia käytetään myös muiden varusteiden kanssa. Kuva 4: Operaatiorunko suunnittelumalli 3.2 Variaationäkymä Simulaatiokehyksen erikoistamista on havainnollistettu kuvitteellisella luokkakaaviolla kuvassa 5. Kehyksen variointi tapahtuu toteuttamalla vaaditut rajapinnat ja lisäämällä tai muuntelemalla perittyihin luokkiin haluttu toteutus. 10/26

11 Kuva 5: Simulaatiokehyksen erikoistaminen Robottikehyksen luokkakaavio on esitetty vielä erikseen kuvassa 6. Kuvan jälkeen on esitettynä variaatiopisteittäin erikoistamismallit. Kuva 6: Robottikehys 11/26

12 Robottikehyksen variaatiopisteiden kuvaukset Muunneltavuusvaatimus: Uuden robotin lisäys Muunneltavuusvaatimuksen kuvaus: Vaatimuksella tarkoitetaan uudenlaisen tekoälyn ohjelmoimista robotille. Robotin tekoäly ilmenee sen alustusvaiheen varustehankinnoissa ja pelivuoron aikana tehtävissä toimenpiteissä. Muunneltavuuden kiinnitysaika: Robotit lisäsään dynaamisesti plugineina Rakenne Selitykset RobotC: Robottikehyksessä oleva abstrakti kantaluokka robottien toiminnallisuudelle MyRobotAI: Uusi sovelluskohtainen robotti initialize(): Tämän funktion avulla robotti sijoitetaan alkutilaansa: mm. sijainti maailmassa ja viitteet malli- ja näkymäosiin sekä engineen. construct(): Tätä kutsutaan kerran kehyksen toimesta kun robotin on aika hankkia varusteet kaupasta. turn(): Tätä kutsutaan jokaisella robotin pelivuorolla. Rajoitteet construct(): Hankittavien varusteiden määrää on rajoitettu käytettävissä olevien ostovarojen mukaan (account). Erikoistus ei saa luoda itse uutta ShopAccount rajapinnan toteuttavaa oliota. turn(): Vuoron aikana tehtävien toimenpiteiden määrää on rajoitettu käytettävissä olevien vuorokrediittien muodossa (credit). Erikoistus ei saa luoda itse uutta TurnCredit rajapinnan toteuttavaa oliota. 12/26

13 Muunneltavuusvaatimus: Uuden varustetyypin luonti Muunneltavuusvaatimuksen kuvaus: Uuden suojiin, moottoriin jne. rinnastettavan varustetyypin luonti Muunneltavuuden kiinnitysaika: Käännösaikana Rakenne Selitykset Feature: Kaikkien varusteiden kantaluokka. Armor, Motor, Gun ja Radar: Robottikehyksessä oletuksena olevat varustetyypit. Nämä määrittelevät kunkin varustetyypin käyttörajapinnan ja tarvittaessa myös osan toteutuksesta. RobotM: Yleinen robottien MVC-arkkitehtuurimallin mukainen malliosa. MyFeature: Oma varuste MyRobotM: Oma erikoistettu versio robotin malliosasta, joka voi koostua myös uudesta varustetyypistä. RobotC: Robottikehyksen mukainen robotin kontrolleriosa, joka mm. luo robotin malliosan. MyRobotC: Sovelluskohtainen robotin kontrolleriosa, joka tulee muuttaa luomaan robotin sovelluskohtainen malliosa. Rajoitteet MyRobotM: Perityn RobotM:n jäsenmuuttujien arvot pitää lukea get() funktioilla ja asettaa set() funktioilla MyFeature: Perityn Feature-luokan jäsenmuuttujien arvot pitää lukea get() funktioilla ja 13/26

14 asettaa set() funktioilla Muunneltavuusvaatimus: Uuden varusteen luonti Muunneltavuusvaatimuksen kuvaus: Uuden suojan, moottorin jne. tyyppisen varusteen luonti Muunneltavuuden kiinnitysaika: Käännösaikana Rakenne Selitykset Armor: Suojien kantatyyppi Light-, Basic-, ja HeavyArmor: Robottikehyksen mukana toimitettavat kolme erilaista suojatyyppiä. Näiden nimi mukailee suojan tehokkuutta. AbstractFeatureFactory: Abstrakti tehdas -suunnittelumallin mukainen tehdas, jonka avulla on mahdollista luoda robottikehyksen mukana toimitettavia varusteita (tarkat tyypit eivät ole kuvassa). MyFeatureFactory: Oma varustetehdas, joka osa vähintään luoda omia varusteita. Robottikehyksen mukana tulevista varusteista tehdas voi valita haluamansa joukon, jotka on sen avulla mahdollista luoda. MyArmor: Oma sovelluskohtainen suojatyyppi. Rajoitteet MyFeatureFactory: Tämän tulee tarjota metodi MyFeature tyyppisten varusteiden luomiseen 14/26

15 Muunneltavuusvaatimus: Uusi pelityyppi Muunneltavuusvaatimuksen kuvaus: Uudenlaisen pelityypin toteuttaminen erikoistuksessa. Muunneltavuuden kiinnitysaika: Käännösaikana Rakenne Selitykset RoboEngine: Robottisimulaatioiden hallinnasta vastaava luokka. RoboTimer: Ajastustapahtumista vastaava luokka. Kutsuu RoboEngine:n timertick() funktiota asetetuin väliajoin. MyEngine: Oma erikoistettu toteutus RoboEngine:stä. Rajoitteet MyEngine/timerTick(): Tämän tulee tarkastaa onko jokin robotti voittanut pelin ja jos ei ole, niin antaa kullekin robotille suoritusaikaa kutsumalla robotin kontrolleriosan turn() -funktiota. MyEngine/checkForWinner(): Tämän tulee palauttaa joko pelin voittanut robotti tai null. MyEngine/nextRobot(): Tämän tulee palauttaa seuraavana vuorossa oleva robotti. Erilaiset pelisäännöt enginessä voivat myös vaikuttaa robottien tekoälyn ohjelmointiin. 4 Arkkitehtuurin arviointi 15/26

16 4.1 Laatuvaatimukset ja skenaariot Laatuvaatimus Tarkempi kuvaus Skenaario Muunneltavuus Sovelluksen käyttöliittymän variointi Erikoistaja voi koodausaikana vaikuttaa sovelluksen käyttöliittymään. Sovelluskohtainen työkalupalkki Vaikka työkalupalkki kuuluukin käyttöliittymään niin käyttöliittymäkehys jättää tämän täysin auki, koska eri sovelluksissa tarvitaan erilaisia kontrollointitapoja simulaation ajoon. Simulaatiokehyksen on tarjottava yleiskäyttöinen työkalupalkki simulaatioiden ajoon. Erilaiset simulaatio-oliot Erilaisten simulaatio-olioiden tarve on on selvä, koska samassa simulaatiossa voi olla tarve erilaisille olioille. Simulaation suoritus Erikoistuksen on jollain tapaa suoritettava simulaatiota esim. askel kerrallaan. Simulaation visualisointi: ulkoasu Simulaatio-olioiden ulkoasu tulee olla erikoistajan päätettävissä Simulaation visualisointi: tilaikkuna Tilaikkunan tietoja varten Sovelluksen näytön eri osaalueiden (valikko, työkalupalkki tai näyttöalue) järjestyksen vaihtaminen tai oletustoteutuksen korvaaminen uudella. Onnistuu yhdessä työpäivässä. Erikoistaja tarvitsee sovelluskohtaista työkalupalkkia ja tekee sitä varten oman toteutuksen. Toteutus kestää kaksi työpäivää. Erikoistaja mallintaa simulaatio-oliot ja toteuttaa niiden käyttäytymisen ja ulkoasun. Yhden simulaatioolion toteuttaminen onnistuu työpäivässä. Erikoistaja tekee toteutuksen mitä tapahtuu simulaation käynnistyksen sovelluskohtaisesta työkalupalkista jälkeen ja miten simulaation suoritusta hallitaan. Toteutus valmistuu työpäivässä. Erikoistaja määrittelee simulaatio-oliolle vapaavalintaisen ulkoasun. Ulkoasun määritys onnistuu kahdessa tunnissa. Erikoistaja määrittää simulaatio-olion palauttamaan tarpeelliset tiedot. Tarpeellisten tietojen määritys onnistuu 16/26

17 Suorituskyky Laatuvaatimus Tarkempi kuvaus Skenaario simulaatio-olioiden tulee osata kertoa tarpeelliset tiedot Simulaatiomaailman variointi Maailman koon muuttaminen tulee olla mahdollista. Sovelluskohtaisen robotin luonti Robottikehyksen erikoistuksessa tulee olla mahdollista lisätä erilaisia robotteja Sovelluskohtaisen robotin varustetyypin luonti Robottikehyksen erikoistuksessa tulee olla mahdollista määrittää uusia varustetyyppejä Sovelluskohtaisen varusteen luonti Robottikehyksen erikoistuksessa tulee olla mahdollista määrittää uusia varusteita olemassa oleviin tyyppeihin Sovelluskohtainen engine esim. eri sääntöjä varten Robottikehyksen erikoistuksessa pitää pystyä vaikuttamaan simulaation kulkuun esim. erilaisten pelisääntöjen muodossa. Erikoistuksen käyttäjä haluaa tehdä ison simulaation ja sijoittaa simulaatio-olioita paljon maailmaan. Pieni vasteaika toiminnoissa kahdessa tunnissa. Sovelluksen erikoistajan tulee ilmoittaa maailman oletuskoko ja käyttäjä voi muuttaa kokoa myöhemmin ajon aikana. Toiminnallisuuden lisäämien onnistuu työpäivässä. Robottikehyksen erikoistaja haluaa määrittää uuden, muista erilaisesti käyttäytyvän robotin. Robotin luominen onnistuu työpäivässä. Robottikehyksen erikoistaja tarvitsee jotain mielivaltaista uutta varustetta robotissaan. Varustetyypin luominen onnistuu työpäivässä. Robottikehyksen erikoistaja haluaa määrittää jonkin olemassa olevan varusteen käyttäytymisen uudestaan. (esim. pidemmän kantaman tutka). Varusteen luominen onnistuu neljässä tunnissa. Robottikehyksen erikoistaja haluaa tehdä uudenlaisen pelisimulaation esim. erilaisilla säännöillä. Enginen toteutus onnistuu kahdessa työpäivässä. Vähintään 500 simulaatio-oliota samassa simulaatiossa Simulaation käynnistys on tapahduttava vähintään 17/26

18 Laatuvaatimus Tarkempi kuvaus Skenaario sekunnissa 4.2 Vaatimusten tarkastelu arkkitehtuurissa Vaatimus Toteutus Analyysi Sovelluksen käyttöliittymän variointi Sovelluskohtainen työkalupalkki Erilaiset simulaatio-oliot Simulaation suoritus Erikoistaja voi varioida käyttöliittymäkehyksen toteutusta ylikirjoittamalla metodit, jotka luovat valikon, työkalupalkit ja varsinaisen sovelluksen näyttöalueen (contents). Näyttöaluetta voi lisäksi varioida siten, että kunkin maailman, tilanäkymän tai lokin saa halutessaan jätettyä pois. Simulaatiokehys tarjoaa perustyökalupalkin uuden simulaation aloittamiseen, simulaation käynnistämiseen, tauon asettamiseen ja lopettamiseen. Lisäksi työkalupalkissa on säädin simulaationopeudelle. Erikoistettava kehys voi halutessaan ottaa tämän käyttöön tai tehdä itse uuden. Perimällä kehyksen luokka ItemModel ja toteuttamalla rajapinnat ItemView ja ItemController. Erikoistus määrittelee tarkemman toteutuksen erilaisille simulaatio-olioille. Simulaatiokehys tarjoaa perustoteutuksen olioiden malliosasta. Yksinkertainen tapa tuottaa tapahtumia määrävälein on käyttää GUI-kehyksen Timerluokkaa. Tätä ajetaan Käyttöliittymän variointi onnistuu helposti jos käyttöliittymän yleinen rakenne sopii sovellukseen (valikon työkalupalkkien yms. keskenäinen sijainti). Sama pätee näyttöalueeseen. Jos simulaatiokehyksen tarjoama perustyökalupalkki ei sovellu, pitää erikoistajan opetella työkalupalkin teko SWT:n avulla. Sovelluskohtainen työkalupalkki on kuitenkin mahdollista tehdä. Erikoistajalla kuluu kontrollerija näkymäosien toteutukseen luultavasti (ainakin ensimmäisillä kerroilla) jonkin verran aikaa. Malliosaan riittänee useimmiten tarpeellisten ominaisuuksien lisääminen ja niiden get/set -funktioiden toteutus. Yksinkertaisen ei reaaliaikaisen simuloinnin toteuttaminen onnistuu helposti, koska mm. synkronointiin ja 18/26

19 Vaatimus Toteutus Analyysi Simulaation visualisointi: ulkoasu Simulaation visualisointi: tilaikkuna Simulaatiomaailman variointi Sovelluskohtaisen robotin luonti käyttöliittymän kanssa samassa säikeessä jotta sen aiheuttamista tapahtumista voi käyttöliittymää piirtää. Tästä seuraa myös se, ettei ajastin ole erityisen tarkka, mutta riittänee yksinkertaiseen, ei reaaliaikaiseen simulointiin. Käyttöliittymäkehys ei tarjoa muita perusprimitiivejä simulaation visualisointiin kuin SWT:n Image-luokan jonka instanssin kehys pyytää piirtäessään simulaatio-olioita. Tämän kuvan käyttöliittymäkehys piirtää sen keskipisteen kohdalle halutulla pyöräytyksellä keskipisteen ympäri. Image luokan olion voi joko lukea tiedostosta (esim. jpg tai png) tai sitten piirtää itse käyttämällä SWT:n funktioita imagen käsittelyyn. Simulaatio-olion tulee toteuttaa StatusViewItem rajapinta, jota käytetään tilatietojen välittämiseen käyttöliittymäkehykselle. Tarkkailija suunnittelumallin mukaisesti simulaatio-olioiden tulee ilmoittaa tarkkailijoilleen muutoksistaan. Maailman kokoa muutettaessa se tyhjennetään ensin (tai ainakin maailmaa pienennettäessä tulee poistaa maailmalta pudonneet tai siirtää ne reunalle). Erikoistaja tekee uuden robotin perimällä abstraktin RobotC -luokan ja toteuttaa sen poissulkemiseen ei erikoistajan tarvitse kiinnittää huomiota. Jos simulaatiolle halutaan reaaliaikaominaisuuksia muuttuu toteutus monimutkaisemmaksi jo senkin takia ettei SWT salli käyttöliittymän widget:ien käsittelyä muualta kuin käyttöliittymän säikeestä. Ulkoasun määritys tapahtuu käytännössä piirtämällä sopiva kuva kuvankäsittelyohjelmalla ja lataamalla ko. kuva simulaatio-olion näkymää vastaavassa luokassa. Tämä riittää hyvin jos ulkoasua ei joudu skaalaamaan simulaation suorituksen aikana paljoa jolloin vektorigrafiikka olisi parempi. Lisäksi jos simulaatioolion ei halua pyörähtävän keskipisteensä ympäri, vaatii sen huomioon ottaminen kuvan keskipisteen koordinaattien muunnoksen eri pyörähdyskulmilla. Erikoistajalla on täysi kontrolli siitä, mitä tilatietoja näytetään. Tilatietoja ei kuitenkaan voi tämän avulla muokata Maailman koon muuttaminen onnistuu, koska se on toteutettuna jo simulaatiokehyksessä. Robotin käyttäytymisen muuttaminen onnistuu melko helposti. Jos tarvitaan muita 19/26

20 Vaatimus Toteutus Analyysi Sovelluskohtaisen robotin varustetyypin luonti Sovelluskohtaisen varusteen luonti Sovelluskohtainen engine esim. eri sääntöjä varten Vähintään 500 simulaatio-oliota samassa simulaatiossa abstraktit funktiot. Varustetyyppi luodaan perimällä robottikehyksen abstrakti luokka Feature. Tämän lisäksi joutuu myös lisäämään robotin malliosaan (RobotM), jotta varusteen voi ottaa käyttöön. Varuste luodaan perimällä haluttu abstrakti varustetyyppi ja toteuttamalla sen vaadittu rajapinta. Tämän lisäksi pitää myös lisätä varusteen luontimekanismi käytettyyn varustetehtaaseen. Enginen erikoistaminen tapahtuu perimällä robottikehyksen luokka RobotEngine ja ylimäärittämällä sen halutut funktiot. Esim. sääntöjen tapauksessa ko. funktiot ovat timertick(), checkforwinner() ja nextrobot(). Simulaatiokehyksen simulaatiomaailmaa vastaavan luokan eli SimulationWorld:n pitää tallentaa simulaatio-oliot sellaiseen tietorakenteeseen, joka mahdollistaa vaatimuksen täyttymisen muutoksia esim. robotin malliosaan, niin silloin joutuu toteuttamaan enemmän. Varustetyypin luominen on sinällään helppoa, mutta sen vaatimat muutokset robotin kontrolleri- ja malliosiin tekevät varustetyypin lisäämisestä kankeaa. Varusteen lisääminen onnistuu. Enginen erikoistaminen näiden funktioiden osalta onnistuu. Koska simulaatiokehys toteutetaan Java:lla voi simulaatiokehyksen SimulationWorld pitää simulaatio-oliot hajautustaulu muotoisessa tietorakenteessa (HashMap) avaimena olion id. Tällöin ei ole ongelmia selviytyä suuremmastakaan joukosta simulaatio-olioita. Raja simulaatio-olioiden määrälle tulee vastaan viimeistään kun SWT:n avulla piirtää olioita, jolloin alustasta riippuen kuviin liittyviä kahvoja (handle) ei ole rajatta tarjolla. Esim. win32 alustalla raja on kokeilujen mukaan /26

21 Vaatimus Toteutus Analyysi Pieni vasteaika toiminnoissa Simulaatiokehyksen toiminnot on tehty nopeasti suoritettaviksi. Koko järjestelmän suorituskykyyn vaikuttaa myös erikoistuksen suorituskyky. Skenaariona ollut simulaation käynnistyksen vasteaika on riippuvainen erikoistuksesta. Esim. Game-of-Life:ssa aluksi pelaaja asettaa elävät solut pelialueelle ja simulaation käynnistämisvaiheessa luodaan tarvittava määrä ei-eläviä soluja. Näitä ovat kaikki loput pelialueen solut. Suurella pelialueella tämä luonnollisesti kestää pidempään. 5 Esimerkkierikoistus Erikoistuksen luokkakaavio on havainnollistettu kuvassa 7. Kuva 7: Robottisota-erikoistuksen luokkakaavio 21/26

22 Luokka: Basic-, Light-, ja HeavyArmor Vastuu: Suojavarustetyypin sovelluskohtaiset erikoistukset Kuvaus: Nimiensä mukaisesti suojia on 3 eri tehoista ja hintaista vaihtoehtoa Luokka: BasicEngine Vastuu: Robotin liikkumisnopeuden laskeminen. Kuvaus: Perusmoottori robotille. Luokka: Laser ja Mortar Vastuu: Aseistus Kuvaus: Laser suora-ammunta-ase ja kranaatinheitin suoraan ja epäsuoraan tuleen. Luokka: FeatureFactory Vastuu: Robottisodan sovelluskohtaisten varusteiden luominen Kuvaus: Käytetään em. varusteiden luonnissa Luokka: BasicRadar Vastuu: Toisten robottien tutkaaminen Kuvaus: Perustutka Luokka: RobotWarGameEngine Vastuu: Robottisota pelin pyöritys Kuvaus: Toimii kaikki vastaan kaikki -säännöillä Luokka: ExplosionV, ExplosionM, TrailV ja TrailM Vastuu: Räjähdyksen ja aseen jäljen näyttäminen maailmassa Kuvaus: Vastaa em. olioiden näkymä ja malliosia. Koska nämä ovat vain yhden pelivuoron ajan näkyvillä, eivätkä ne osallistu simulaation millään tavalla, ei näillä tarvita kontrolleriosaa lainkaan. Luokka: Robot1AI ja Robot2AI Vastuu: Robottien 1 ja 2 tekoäly Kuvaus: Nämä kuvitteelliset luokat vastaavat robottisimulaatioon käyttäjän ohjelmoimia robotteja. Näissä luokissa on toteutettuna robotin varustaminen varusteilla sekä funktio, jota kutsutaan aina robotin pelivuorolla. 22/26

23 5.1 Käytetyt suunnittelumallit Tässä vain listattu käytetyt suunnittelumallit, [voisivat olla myös luvun 3 tapaan kuvattuna] Abstract factory FeatureFactory:n ja RobotFactoryn tapauksessa Mediator aseen käytön yhteydessä kun aseen ampumisen jälkeen lasketaan vahingot roboteille. 5.2 Pelisimulaation suorituksen kuvaus RoboEngine käyttää RoboTimer luokan oliota luomaan tapahtumia säännöllisin väliajoin simulaatiota ajettaessa. Tällaisen tapahtuman tapahtuessa RoboEngine antaa aina kullekin elossa olevalle robotille pelivuoron. Kuvassa 8 on esitetty yksittäisen pelivuoron eteneminen. Kuva 8: Pelivuoro Pelivuoron selostus 1. Simulaation ollessa käynnissä RoboTimer kutsuu tasavälein RoboEnginen timer- Tick() -funktiota. RoboEngine tarkastaa ensin, että onko jäljellä enää yksi robotti, jolloin se on voittaja. Muutoin jatketaan simulaation ajoa. 23/26

24 2. RoboEngine pyytää maailmaa poistamaan kaikki pelkästään näkymään kuuluvat item:t, kuten räjähdykset tai aseen jäljet. 3. Paluu 4. RoboEngine kutsuu vuorossa olevan robotin turn() -funktiota. 5. Robotille ohjelmoitu tekoäly saa tehdä vuoron aikana mitä tahansa: muuttaa ajonopeutta (säätämällä moottorin tehoa) tai -suuntaa ja käyttää ominaisuuksia vastustajien löytämiseen sekä tuhoamiseen. 6. Paluu 7. Paluu 8. RoboEngine kutsuu vuorossa olleen robotin mallia liikuttamaan itseään ajosuuntaansa säädetyn moottorin tehon edellyttämä matka. 9. Paluu 10. Paluu 5.3 Testaus Tähän on koottu esimerkin omaisesti joitakin järjestelmän toimintaa testaavia testitapauksia. Pelkästään simulaatiokehyksen toiminnan testaamiseen vaadittaisiin muutama erikoistus ja sama pätee myös käyttöliittymäkehykseen, joten tässä ei ole tarkoitus pyrkiä testaamaan järjestelmää kattavasti. Testitapauksen nimi: Simulaation toiminta Kuvaus: Testitapaus testaa simulaation suoritusta ja sen päättymistä. Lähtöehdot: Sovellus on käynnistetty ja simulaatiomaailma on tyhjä Sovellukseen on ohjelmoitu vähintään yksi robotti, joka osaa etsiä ja tuhota toisia robotteja Suoritus: 1. Testaaja sijoittaa vähintään kaksi robottia pelialueelle 2. Testaaja käynnistää simulaation 3. Robotit taistelevat kunnes on enää yksi hengissä 4. Simulaatio päättyy Loppuehdot ja hyväksyntä: Simulaatio päättyy kun yksi robotti on enää hengissä Jos käy niin, että robotit ajautuvat liian kauaksi toisistaan eivätkä ne enää osaa etsiä toisiaan, pysäytetään simulaatio ja aloitetaan testitapauksen suoritus alusta. Testitapauksen nimi: Robottien varusteiden toimivuus 24/26

25 Kuvaus: Tällä testitapauksella testataan erilaisten robottien varusteiden toimivuutta ja tehokkuutta. Lähtöehdot: Sovellukseen on ohjelmoitu kaksi robottia, joiden lähdekoodi on saatavilla muokkaamista varten. Näistä toinen on sellainen, että pysyy koko ajan paikallaan eikä ammu ja toinen on sellainen että etsii vihollisen ja yrittää tuhota sen. Sovellus on käynnistetty ja simulaatiomaailma on tyhjä Suoritus: 1. Testaaja laittaa yhden kumpaakin robottityyppiä simulaatiomaailmaan 2. Testaaja käynnistää simulaation 3. Testaaja tarkkailee paikallaan olevan energiaa ja suojien tasoa sekä liikkuvan robotin ampumatarkkuutta ja yleistä toimintaa. 4. Simulaatio päättyy 5. Testitapaus voidaan suorittaa useampaan kertaan vaihtamalla simulaation osallistuvien robottien varustusta Loppuehdot ja hyväksyntä: Testaajan tarkkailun perusteella päätellään ovatko simulaatioon osallistuneiden robottien varusteet toimivia. 5.4 Pelaajan toimien rajoittaminen (Tämä on itseasiassa toteutettu jo robottikehyksessä) Jotta peli olisi mielekäs, pitää robotin ohjelmoijan toimia rajoittaa. Toteutuksessa on huomioitu seuraavat rajoittamistavat: varusteiden ostaminen ja pelivuoron aikana tehtävät toimenpiteet. Lisäksi liikkumista on tavallaan rajoitettu siten, että kukin robotti liikkuu vasta vuoronsa päätteeksi. Varusteiden ostamista ja pelivuoroa on rajoitettu samalla menetelmällä: robotin tekijän toteuttaman funktiot saavat kutsunsa parametrina olion, jolla on tietty määrä krediittiä jäljellä. Kukin oletettu tapahtuma, jonka robotin ohjelmoija voi tässä tilanteessa tehdä, ottaa kyseisen olion parametrinaan ja vähentää rasituksensa mukaan olion krediittiä. Pelaajalle tarjotaan vain rajapinta kyseisten krediitti-olioiden käyttöön ja tästä rajapinnasta ei löydy funktioita krediittien kasvattamiseen. Varusteiden oston tapauksessa kyseessä krediitti-olio vastaa siis pankkitiliä ja pelivuoron tapauksessa kunkin varusteen käytöllä (lähinnä aseet ja tutka) on jokin tietty hinta. Aseiden ja tutkan tehon sekä tarkkuuden lisäksi niiden keskenäistä paremmuussuhdetta voidaan siis myös säätää käytön hinnan perusteella. 5.5 Oman robotin tekeminen Ohjeet robotin tekemiseksi Robotin toteuttavan luokan tulee kuulua pakkaukseen fi.tut.ohar.hsuontau.robo- Sim.plugins 25/26

26 Robotin tulee periä luokka fi.tut.ohar.hsuontau.robosim.controller.robotcontroller Robotin tulee toteuttaa funktio public void construct(featureshop shop, ShopAccount account) Tätä funktiota kutsutaan kerran robotin alustusvaiheessa. Sen tarkoituksena on varustaa robotti eri varusteilla (suojat, moottori, tutka ja aseet). Varusteet ostetaan parametrina saadulta FeatureShop oliolta. Ostetut varusteet on asetettava mallille tyyliin getmodel().setarmor(armor); Robotin tulee toteuttaa funktio public void turn(turncredit credit) Tätä funktiota kutsutaan kerran jokaisella robotin pelivuorolla Vuoron aikana tarkoitus on esim. etsiä muita robotteja ja niitä löydettäessä ampua niitä, tai mitä ikinä sitten kuuluukin kyseisen robotin taktiikkaan :-) Pelivuoron lopuksi robotti siirtyy ajosuuntaansa robotin tehoa vastaavan matkan. Robotin käännetty.class tiedosto tulee sijoittaa pakkauksen nimen osoittamaan hakemistoon fi/tut/ohar/hsuontau/robosim/plugins 26/26