Ohjelmiston toteutussuunnitelma Ryhmän nimi: Crossing Tekijät: Timo Nummenmaa (PM) Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått Toimeksiantaja: Timo Poranen (UTA) Muutospäivämäärä: 6.3. 2005 Versio: 1.0.0 1
Sisällysluettelo 1 Johdanto...4 1.1 Tavoitteet... 4 1.2 Projektin laajuus... 5 1.3 Ohjelman ympäristö...5 1.4 Tärkeimmät rajoitteet...6 2 Datasunnitelma... 6 3 Arkkitehtuuri- ja komponenttitason suunnitelma...6 3.1 Ohjelman rakenne... 6 3.1.1 Arkkitehtuurikaaviot... 7 3.1.2 Vaihtoehdot...10 3.2 libgtl... 11 3.2.1 libgtl:n liittymäkuvaus...12 3.3 libutag... 12 3.3.1 libutag:n liittymäkuvaus...12 3.4 mops...12 3.4.1 mops:n prosessikuvaus...12 3.4.2 mops:n liittymäkuvaus... 13 3.4.3 mops:n algoritmikuvaus...14 3.5 mps...15 3.5.1 mps:n prosessikuvaus...15 3.5.2 mps:n liittymäkuvaus... 15 3.5.3 mps:n algoritmikuvaus...17 3.6 crossing... 17 3.6.1 crossingin prosessikuvaus... 17 3.6.2 crossingin liittymäkuvaus...18 3.6.3 crossingin algoritmikuvaus... 18 3.7 Ohjelmiston käyttöliittymän kuvaus... 18 3.7.1 Liittymät ulkoisiin laitteisiin...18 3.7.2 Ulkoiset systeemiliittymät...18 4 Käyttäjän käyttöliittymän suunnitelma...18 4.1 Käyttäjän käyttöliittymän kuvaus... 19 5 Rajoitteet...19 2
6 Testausasiat...19 6.1 Testiluokat... 20 6.2 Tehokkuusrajat...20 6.3 Kriittisten komponenttien tunnistaminen... 20 7 Liitteet...20 7.1 Paketointi- ja asennusasiat...20 7.2 MPS-suoritusarvoja... 21 7.3 MOPS-suoritusarvoja...23 7.4 Versiohistoria...24 3
1 Johdanto Toteutussuunitelmadokumentin kuvaa UTAG:n arkkitehtuurin. Lisäksi dokumentissa esitellään mps-, mops- ja crossing-ohjelmat, jotka toimivat kirjaston käyttöesimerkkeinä 1.1 Tavoitteet Projektin tavoitteena on suunnitella ja toteuttaa ohjelma graafien ominaisuuksien, kuten risteämäarvojen, suurimman ulkotasograafin (mops) tai suurimman tasograafin (mps), laskemiseen. Lisäksi tavoitteena on toteuttaa se niin, että jatkossa tämän pohjalle voivat kohdekäyttäjät rakentaa omia sovelluksia. Lähtökohtana toteutuksessa on olemassa oleva apptopinv-ohjelma, josta muokataan vaatimusmääritysten mukainen uusi ohjelma. Projekti on tutkimusluontoinen, jolloin osa työstä koostuu tässä tapauksessa uusien algoritmien kehittelystä ja testauksesta. Tästä johtuen tarkkojen vaatimusten esittäminen toteutuksen osalta on varsin vaikeaa. Olemmekin priorisoineet toteutusvaiheen tehtäviä. Ohjelman toiminnan kannalta olennaisimmat toiminnot ja muut vaatimukset ovat erotettu toisistaan. Ensisijaiset tavoitteet: kaupallisen LEDA-kirjaston poistaminen kaupallisen kirjaston toimintojen korvaaminen GTL-kirjaston sekä omien funktioiden avulla graafin risteämäarvon laskevan satunnaistetun algoritmin toteutus ulkokehägraafin ristämäarvon laskevan algoritmin toteutus ohjelman arkkitehtuurillinen uudelleenjärjestäminen MPS (suurin mahdollinen alitasograafi) ja MOPS (suurin mahdollinen ulkoalitasograafi) algoritmien tekeminen satunnaisten graafien generointi Toissijaiset tavoitteet: graafien tallentaminen halutussa tiedostomuodossa graafien visualisointi näytölle oman graafikirjaston luonti laajennettavuuden mahdollistaminen lisäalgoritmien kehittely 4
1.2 Projektin laajuus Projektin päätarkoitus on luoda ohjelmistoarkkitehtuuri graafiongelmien käsittelyn helpottamiseksi. Samalla luodaan muutama (mps, mops, crossing) komentorivipohjainen ohjelma, jotka kuvataan tarkemmin. Syötteet: parametrit, jotka määräävät graafista laskettavan ominaisuuden parametrit, jotka vaikuttavat algoritmin valintaan ja sen toimintaan satunnaisesti generoitava graafi tiedostosta ladattava graafi Tulokset: graafista lasketut arvot arvojen laskemiseen kulunut aika tiedostoon halutussa formaatissa tallennettu graafi graafin visualisointi näytölle 1.3 Ohjelman ympäristö Asiakas käyttää ohjelmaa graafien tutkimiseen testaamalla erilaisten algoritmien tehokkuutta graafien risteämäarvojen laskemisessa. Olemassa olevaan apptopinv-ohjelmaan verrattuna toteutettavan ohjelman tulisi olla laajennettavuudeltaan ja muokattavuudeltaan hyvä, jotta jatkossa asiakas pystyisi lisäämään helposti uusia tutkimusalgoritmeja. Projektin eräs tarkoitus on pilkkoa apptopinv-ohjelman toiminnallisuus pienemmiksi, tiettyyn osa-alueeseen suunnatuiksi, erillisiksi ohjelmiksi. Aikomuksena on myös laatia täysin apptopinv:ia vastaava ohjelma, joka olisi kuitenkin lähinnä tarkoitettu projekin sisäiseen käyttöön ja testaukseen. Ohjelman toteutuksessa tullaan hyödyntämään vapaasti saatavilla olevaa GTL-graafikirjastoa. Tulevaisuutta varten tämän kirjaston tarjoamat palvelut eriytetään muusta ohjelmasta niin, että asiakas pystyy tarvittaessa korvaamaan kirjaston tarjoamat palvelut paremmaksi katsomillaan toteutuksilla. 5
1.4 Tärkeimmät rajoitteet Teknisiä rajoitteita toteutukselle aiheuttavat GTL-graafikirjaston käyttö sekä pyrkimys tehdä ohjelmasta käyttöjärjestelmäriippumaton. GTL:ssä lisäksi joudumme tyytymään versioon 0.3.3, joka on viimeinen versio vapaassa levityksessä ja on julkaistu vuonna 2000. Tämän jälkeen GTL on muuttunut kaupalliseksi. Projektin aikataulusta johtuen loppupäähän ajoitettujen tehtävien ja ominaisuuksien toteuttamiseen saattaa jäädä vähän aikaa. 2 Datasunnitelma Pyrimme käyttämään jo olemassa olevia tietorakenteita ja täten pyrimme hyödyntämään STLkirjaston rakenteita mahdollisimman monipuolisesti. STL on tunnettu ja varsin toimivaksi testattu C++-kirjasto. STL:n palveluista erityisesti set-, list- ja vector-rakenteita tullaan käyttämään toteutuksessa. Väliaikaisiksi tietorakenteiksi voidaan lukea omat Edge- ja Node-luokkamme. Ne toimivat niin sanottuina wrapper-luokkina, jotka kapseloivat varsinaisen tiedon solmuista ja kaarista. Kapseloivan luokan instanssi muuttuu jokaisella kerralla, vaikka se kapseloisikin saman GTL:n tietoalkion. 3 Arkkitehtuuri- ja komponenttitason suunnitelma 3.1 Ohjelman rakenne Ohjelma sisältää GTL- ja UTAG-kirjastot sekä mops-, mps- ja crossing-komentorivikäskyt. Lisäksi UTAG:n komponenteille laaditaan kattavat yksikkötestit. Yksikkötestit dokumentoidaan testien tekovaiheessa ja ne liitetään osaksi projektin testaussuunnitelmaraporttia (http://www.uta.fi/~jr69996/crossing/testaussuunnitelma-1.1.0.pdf). UTAG-kirjasto ja muut ohjelmat tullaan toimittamaan avoimen GPL-lisenssin 1 alaisuudessa. Kääntämistä varten komponentit varustetaan GNU-mallin mukaisella toiminnallisuudella: configure, make, make install. Riippuvuussuhteiden takia esimerkiksi UTAG-kirjaston 1 http://www.gnu.org/copyleft/gpl.html 6
kääntäminen vaatii GTL:n kääntämistä ensiksi ja UTAG:tä käännettäessä tulee GTL-kirjaston löytyä linkitystä varten. Tämä käyttöskenaario tullaan dokumentoimaan tarkasti käyttöohjeessa ja miettimään mahdollisimman helpoksi käyttäjille. Windows-ympäristössä UTAG:lle on luotu MS Visual Studio.NET:n projektitiedosto ja täten sen pystyy rakentamaan kyseistä ohjelmistoa apuna käyttäen. Komponenttien yhteyteen tullaan lisäämään Visual Studio -projektitiedostot ja täten komentoriviohjelmien kääntäminen onnistuu suhteellisen helposti. Kirjastoja voi hyödyntää staattisesti linkittämällä omaan ohjelmaan tai dynaamisesti linkittämällä ja asentamalla kirjastot asianmukaisiin hakemistoihin. Jälkimmäinen lienee *nixympäristössä yleisempi käyttöskenaario. Staattinen linkitys ja kääntäminen on puolestaan Windows-ympäristössä suhteellisen helppoa, vaikkakin ei välttämättä yleisin tapa. 3.1.1 Arkkitehtuurikaaviot Seuraavissa kolmessa kuvassa esitetään arkkitehtuurimme rakenne. Jaoimme kaavion kolmeen osaan ihan selkeyden vuoksi. Yhdessä kuvassa malli olisi ollut aivan liian sekava. Nyt näistä kuvista näkyy selvästi luokkarakenteet. Lisäksi tämä jako oli helppo tehdä, sillä näin arkkitehtuurista erottuu selvästi eri osa-alueet, joista enemmän kuvien yhteydessä. Ensimmäisessä kuvassa esitetään keskesimmät luokat, eli Graph-, Node- ja Edge-luokat. Seuraavassa kuvassa on algoritmiluokkia ja viimeisessä IO-luokat. 7
Kuva 1: Base UTAG-arkkitehtuurin perusrakennuspalikat ovat Graph-, Node- ja Edge-luokat, jotka kätkevät sisäänsä GTL-kirjaston vastaavat toteutukset. Luokat on suunniteltu siten, että GTL-kirjasto voidaan korvata omalla ratkaisulla mahdollisimman helposti. Graph Graafi on ehdottomasti tärkein komponentti koko kirjastossa. Suurin osa graafeihin, solmuihin ja kaariin kohdistuvista operaatioista tapahtuu juuri graafiluokan kautta. Esimerkiksi käyttäjä luo uusia solmuja ja kaaria graafiin itse Graafiluokan instanssin kautta. Sekä solmuihin että kaariin voidaan liittää lisäinformatiota. Tämä tapahtuu ensiksi liittämällä oikeanlainen tietoalkio (tyyppiä DataElement) Graafiluokkaan metodeilla setdataelementfornode ja setdataelementforedge. Tietylle kaarelle tai solmulle kuuluvaa tietoalkiota voi vuorostaan kysellä metodeilla getdataelementfornode ja getdataelementforedge. 8
Node UTAG-kirjaston Node luokka sisältää tarvittavat metodit GTL:n node-luokan tietojen käsittelyyn. Luokan pääasia on toiminnallisuus solmuun liitettyjen kaarien (getadjedges) ja vierussolmujen (getadgnodes) tutkimiseen. getid antaa solmuun sidotun ainulaatuisen tunnusnumeron. Edge Kuten solmukin, kaari käärii GTL-kirjaston edge-luokan sisäänsä ja tarjoaa tarvittavat operaatiot edge-luokan tietojen käsittelyyn. Kaareissa on informaatio solmuista, jotka kaari yhdistää, vaikka graafit ovatkin suuntaamattomia. Täten source-metodi palauttaa sen solmun, josta kaari katsotaan lähtevän ja target-metodi palauttaa solmun, johon kaaren katsotaan johtavan. Kuva 2: Algorithm 9
Algorithm-luokka toimii kantaluokkana kaikelle toiminnallisuudelle, joka käsittelee Graafeja tai muiden algoritmien luomaa dataa Graafeista. Tämä osa luokkakaaviosta täydentyy sen mukaan miten eri algoritmeja totetutetaan. Tällä hetkellä eriteltynä on Graafeja käsittelevät algoritmit, joihin kuuluvat mm. kaktuspuualgoritmit CA, CA1 ja CA2 (jotka tarkkaan ottaen kuuluvat PlanarityAlgorithm luokan alaisuuteen). Tämä dokumentti jäi hieman jälkeen uusista ideoista, mikä näkyy etenkin tässä Algorithmluokassa. Ensinnäkin Algorithm-luokan metodit jätetään kaikki muut paitsi run pois. Kaikki toimenpiteet toteutetaan ylimäärittelemällä run. CA-, CA1- ja CA2-algoritmit jaetaan kolmeen osaan. Varsinainen algoritmi etsii kaikki kolmionmuotoiset silmukat, Join yhdistää saadut silmukat ja Fill lisää kaaria taso-ominaisuuden kärsimättä. Luokkarakenteen kannalta mahdollinen ratkaisu on lisätä PlaranityAlgorithmille uusi (vielä nimeämätön yläluokka). Tämän yläluokan alle tulisi myös uusi luokka, jonka nimi olisi esimerkiksi PlaranityToolAlg. Tästä luokasta perittäisiin Join-, Fill- sekä SA-luokat, minkä seurauksena RepetitiveAlgorithmluokka poistettaisiin. Lisäksi dfs:n paikka on vielä ratkaisematta. Kuva 3: FileIO FileIO-kategoriaan kuuluvat kaikki ne luokat, jotka tarjoavat eri tiedostoformaattien sekä lukuettä kirjoitusominaisuuksia. Luokkia laajennetaan ylimäärittelemällä sekä load- että savemetodit. 3.1.2 Vaihtoehdot Vaihtoehtoisia arkkitehtuureja projektin vaatimusten täyttämiseksi ovat: 10
Toteuttaa vaaditut toiminnot yksittäisinä sovelluksina hyvin yksinkertaisen graafitoteutuksen kera. Tässä mallissa ei käytettäisi graafikirjastoa lainkaan, joten tasoominaisuuden testaus jouduttaisiin tekemään itse. Kirjoittaa sovellukset suoraan GTL:ää hyödyntäviksi. Tämän mallin heikkous olisi vaihtaa graafikirjastoa, jolloin sovellukset sisältäisivät algoritmeja GTL-laajennuksina. Kirjoittaa tarvittavat laajennukset GTL:ään. Tämä vaihtoehto on kenties paras, jos GTL olisi edelleen vapaastijaettavissa. Nykytilanteessa laajennetun GTL:n jakaminen saattaisi olla kiusallista. Lisäksi onnistuneet ja yleishyödylliset algoritmit olisivat jopa saattaneet päätyä osaksi jaettavaa GTL:ää melkoinen porkkana. Korvata GTL jollain muulla valmiilla graafikirjastolla. Projektin yhteydessä evaluoiduista graafikirjastoista ainoastaan GTL vaikutti varteenotettavalta vaihtoehdolta LEDA:n korvaajaksi. 3.2 libgtl GTL-graafikirjaston versiot ennen 1.0:aa olivat vapaasti saatavilla ja meidän käytössämme onkin 0.3.3. GTL:n sivuilla mainostetaan kuitenkin edelleen, että kirjasto olisi ilmaiseksi saatavilla tutkimuskäyttöön. Otettuamme yhteyttä tekijöihin kävi kuitenkin ilmi, että sivuston tieto on pahasti vanhentunutta. Kirjaston viimeisin ilmainen versio löytyy esimerkiksi funet ftp:ltä: ftp://ftp.funet.fi/pub/netbsd/packages/distfiles/gtl-0.3.3.tar.gz Kyseessä on suhteellisen vanha versio GTL:stä, eikä se käänny sellaisenaan gcc-kääntäjän versiolla 3.0 eikä uudemmilla. Pakettia ei tosin tarvitse muokata kovinkaan paljon, jotta sen saa kääntymään nykyaikaisemmassa ympäristössä. Tarjoamme GTL:stä oman korjatun version 0.3.3b, jos se on vain laillista. Vaihtoehtoisesti tarjoamme erillisen korjaustiedoston (patch) GTL:n versiolle 0.3.3. UTAG-kirjasto sisältää toiminnallisuuden graafin taso-ominaisuuden testaamiseen, jota hyödynnetään mm. projektin tuottamissa erillisissä sovelluksissa, ja joka on keskeinen osa monia graafialgoritmeja. Koska kyseessä on kirjasto, on mahdollista linkittää se kiinteäksi osaksi omaa ohjelmaa tai käyttää sitä kaikille ohjelmille yhteisenä dynaamisena kirjastona. Käyttötavat ovat ohjelmoijalle hyvin samankaltaiset, mutta ajettavaa käännettyä tiedostoa jaettaessa on huomattava ero, pitääkö kirjasto olla myös asennettuna. 11
3.2.1 libgtl:n liittymäkuvaus GTL:n mukana seuraa otsikkotiedostot kirjaston käyttämiseksi omassa ohjelmassa. Tätä kirjastoa ei tosin ole suunniteltu käytettäväksi suoraan projektin tapauksessa, vaan UTAGkirjasto paketoi GTL:n sisäänsä ja tarjoaa tarvittavat toiminnot sovelluksille. GTL tulisi piilottaa loppukäyttäjältä niin, että hän ei sitä pääse käyttämään, vaan joutuu käyttämään UTAG:n vastaavia luokkia ja tietorakenteita. 3.3 libutag Projektin suunnitteluvaiheesta asti ollaan pyritty rakentamaan omaa kirjastoa, jolla vaadittavat ohjelmat saisi toteutettua. GTL:n epävarman tilanteen takia päätettiin pelata varman päälle, eikä lähdetä tekemään laajennuksia GTL:ään. UTAG-kirjasto hyödyntää soveltuvin osin GTL:ää sellaisenaan, nimeämiskäytäntöä lähinnä muokataan. Tarkoituksena on samalla tehdä alustava rakenne omalle graafikirjastolle, jossa mahdollisimman pienellä vaivalla olisi GTL korvattavissa omilla tai toisen kirjaston luokilla ja funktioilla. GTL:n luokkia kääritään UTAG:ssä, mikä mahdollistaa hyvin dynaamisen per funktio korvaamisen. Lisäksi kirjaston luokkahierarkiassa pyritään ohjaamaan mahdollisten laajennusten ja toteutuksen muotoa. 3.3.1 libutag:n liittymäkuvaus UTAG:n mukana tulevat otsikkotiedostot kirjaston käyttämiseksi. 3.4 mops Projektin vaatimuksiin kuuluu toteuttaa apptopinv-ohjelman suurimman ulkotasograafin etsintä ilman LEDA-kirjastoa. Varsinainen etsintäalgoritmi toteutetaan UTAG-kirjastossa, mutta tämän toiminnon esittelyä varten tehdään lisäksi komentoriviohjelma, joka toimii samalla kirjaston käyttöesimerkkinä. 3.4.1 mops:n prosessikuvaus Ohjelma saa syötteenä tiedostonimen ja toimintaa ohjaavia parametrejä. Tutkittava graafi 12
voidaan joko ladata tiedostosta (gml-, rmf- tai kaarilistamuodossa) tai muodostaa satunnaismenetelmällä. Suurimman ulkotasograafin etsintä koostuu kolmesta algoritmistä. Ensiksi etsitään yksi alustava ratkaisu, joka on yleisesti huono, eli ei ole suurin mahdollinen. Tämän jälkeen seuraava algoritmi saa syötteenään edellisen tulosteen ja pyrkii parantamaan ratkaisua jollain heuristiikalla. Kolmantena suoritetaan simuloitu jäähdytys, joka pyrkii edelleen parantamaan toisen vaiheen löytämää (parempaa) ratkaisua. Simuloitua jäähdytystä ei käynnistetä automaattisesti jokaisen ajon yhteydessä, vaan sen valinta suoritetaan parametrilla. Jokaisen algoritmin yhteydessä on mahdollista tulostaa tietoa sen hetkisestä ratkaisusta ja suorittaa vertailua etsimisen onnistumisesta. Lisäksi on mahdollista tallentaa löytyvä osagraafi tiedostoon gml- tai kaarilistaformaatissa Näitä valinnaisia tulosteita ohjataan suorituksen yhteydessä annettavin parametrein. syöte: graafi tuloste: suurin ulkotasograafi 3.4.2 mops:n liittymäkuvaus Apptopinv-ohjelma tarvitsee parametrinaan ongelman nimen, eli tässä tapauksessa sille annettaisiin käsky -mops. Meillä mops ja mps ovat eriteltyjä eri ohjelmaan, jolloin tätä parametria ei tarvita. Mops-ohjelmalle annetaan kuitenkin komentoriviltä ainakin algoritmin suorituksen lukumäärä, tulostiedosto, käytettävä algoritmi, mahdollinen simuloidun jäähdytyksen käyttö, graafin lähde ja mahdollinen graafin tallennustiedosto. Seuraavassa taulukossa esitellään tarkemmin komentorivikäskyjä. Toistojen määrä Tulostiedosto Algoritmi Numeroarvo tietyn algoritmin toistojen määrälle Tiedosto, johon tulokset kirjataan Valitaan käytettävä algoritmi -ca -ca1 Simuloitu jäähdytys -sa Valitaan, käytetäänkö simuloitu jäähdytystä. Parametrilla -sa käytetään simuloitu jäähdytystä. Jos simuloitua jäähdytys halutaan pois, niin ei anneta parametria ollenkaan. 13
Graafi tiedostosta -f FILENAME -frmf FILENAME Käsiteltävä graafi haetaan tiedostosta. Hyväksyttävät formaatit ovat kaarilista (-f), rmf (-frmf) ja gml (-fgml). FILENAMEn paikalle annetaan tietenkin tiedosto, josta graafi luetaan -fgml FILENAME Laskennallisia graafeja -c V1 V2... Vk -ch k -pl V E Tämä on yksi vaihtoehto graafin lähteeksi, eli rinnakkainen edellisen ja seuraavan kohdan kanssa. Ensimmäinen (-c V1 V2... Vk) komennolla tutkitaan täydellistä k-jakoista graafia, jossa V1, V2... ovat solmusarjojen koko. Seuraavalla (-ch k) luodaan täydellinen hyperkuutio 2 k solmulla. Maksimaalinen tasograafi määrällä V solmuja ja E kaaria luodaan komennolla -pl V E. Viimeinen käsky on vastaava, mutta siinä tutkitaan ulkotasograafia. -opl V E Satunnainen graafi -r V E -rr V D Tallennustiedosto -gml FILENAME Kolmas vaihtoehto graafin lähteeksi. Ensimmäisellä komennolla (-r V E) luodaan satunnainen graafi V:llä solmulla ja E:llä kaarella. Toisessa (-rr V D) luodaan D-regular??? graafi määrällä V solmuja Tämä on valinnainen käsky. Satunnaisesti luotu graafi tallennetaan annetussa muodossa (gml tai kaarilista) haluttuun (FILENAME) tiedostoon. -f FILENAME Kaikkia mahdollisia kombinaatioita ei ole välttämättä tarvetta toteuttaa. Varsinkin tulosteita pitäisi olla helppo muokata lisää omatoimisesti, jos ei sellaisenaan kelpaa: mops [options] graph.gml --verbose, v : tulostelee välivaiheista tietoa --out file, -o file : tallentaa tuloksen gml-formaatissa tiedostoon 3.4.3 mops:n algoritmikuvaus Ohjelman rakenne: 1. lataa graafi 2. satunnainen ratkaisu 14
3. etsi parempi ratkaisu 4. simuloitu jäähdytys 5. tulostus/graafin tallennus Ohjelma käyttää UTAG-kirjaston algoritmeja etsinnässä: -lista luokkien nimistä 3.5 mps Projektin vaatimuksiin kuuluu toteuttaa apptopinv-ohjelmasta suurimman tasograafin etsintä ilman LEDA-kirjastoa. Varsinainen etsintäalgoritmi toteutetaan UTAG-kirjastossa, mutta tämän toiminnon esittelyä varten tehdään lisäksi komentoriviohjelma, joka toimii samalla kirjaston käyttöesimerkkinä. Suurimman tasograafin etsintä on hyvin samankaltainen kuin ulkotasograafin etsintä (mops). 3.5.1 mps:n prosessikuvaus Ohjelma saa syötteenä tiedostonimen ja toimintaa ohjaavia parametrejä. Tutkittava graafi voidaan joko ladata tiedostosta (gml-, rmf- tai kaarilistamuodossa) tai muodostaa satunnaismenetelmällä. Suurimman tasograafin etsintä koostuu kolmesta algoritmistä. Ensiksi etsitään yksi alustava ratkaisu, joka on yleisesti huono, eli ei ole pienin mahdollinen. Tämän jälkeen seuraava algoritmi saa syötteenään edellisen tulosteen ja pyrkii parantamaan ratkaisua jollain heuristiikalla. Kolmantena suoritetaan simuloitu jäähdytys, joka pyrkii edelleen parantamaan toisen vaiheen löytämää (parempaa) ratkaisua. Simuloitua jäähdytystä ei käynnistetä automaattisesti jokaisen ajon yhteydessä, vaan sen valinta suoritetaan parametrilla. Jokaisen algoritmin yhteydessä on mahdollista tulostaa tietoa sen hetkisestä ratkaisusta ja suorittaa vertailua etsimisen onnistumisesta. Lisäksi on mahdollista tallentaa löytyvä osagraafi tiedostoon joko gml- tai kaarilistaformaatissa. Näitä valinnaisia tulosteita ohjataan suorituksen yhteydessä annettavin parametrein. 3.5.2 mps:n liittymäkuvaus Apptopinv-ohjelma tarvii parametrinaan ongelman nimen, eli tässä tapauksessa sille annettaisiin käsky -mps. Meillä mops ja mps ovat eriteltyjä eri ohjelmaan, jolloin tätä 15
parametria ei tarvita. Mps-ohjelmalle annetaan kuitenkin komentoriviltä ainakin algoritmin suorituksen lukumäärä, tulostiedosto, käytettävä algoritmi, mahdollinen simuloidun jäähdytyksen käyttö, graafin lähde ja mahdollinen graafin tallennustiedosto. Seuraavassa taulukossa esitellään tarkemmin komentorivikäskyjä. Mopsin vastaavista käskyistä mpsohjelma ei poikkea kovinkaan paljoa. Ainoastaan komento -ca2 on lisätty algoritmivalintaan. Toistojen määrä Tulostiedosto Algoritmi Numeroarvo tietyn algoritmin toistojen määrälle Tiedosto, johon tulokset kirjataan Valitaan käytettävä algoritmi -ca -ca1 -ca2 Simuloitu jäähdytys -sa Graafi tiedostosta -f FILENAME -frmf FILENAME Valitaan, käytetäänkö simuloitu jäähdytystä. Parametrilla -sa käytetään simuloitu jäähdytystä. Jos simuloitua jäähdytys halutaan pois, niin ei anneta parametria ollenkaan. Käsiteltävä graafi haetaan tiedostosta. Hyväksyttävät formaatit ovat kaarilista (-f), rmf (-frmf) ja gml (-fgml). FILENAMEn paikalle annetaan tietenkin tiedosto, josta graafi luetaan -fgml FILENAME Laskennallisia graafeja -c V1 V2... Vk -ch k -pl V E Tämä on yksi vaihtoehto graafin lähteeksi, eli rinnakkainen edellisen ja seuraavan kohdan kanssa. Ensimmäinen (-c V1 V2... Vk) komennolla tutkitaan täydellistä k-jakoista graafia, jossa V1, V2... ovat solmusarjojen koko. Seuraavalla (-ch k) luodaan täydellinen hyperkuutio 2 k solmulla. Maksimaalinen tasograafi määrällä V solmuja ja E kaaria luodaan komennolla -pl V E. Viimeinen käsky on vastaava, mutta siinä tutkitaan ulkotasograafia. -opl V E Satunnainen graafi -r V E -rr V D Kolmas vaihtoehto graafin lähteeksi. Ensimmäisellä komennolla (-r V E) luodaan satunnainen graafi V:llä solmulla ja E:llä kaarella. Toisessa (-rr V D) luodaan D-regular??? graafi määrällä V solmuja 16
Tallennustiedosto -gml FILENAME Tämä on valinnainen käsky. Satunnaisesti luotu graafi tallennetaan annetussa muodossa (gml tai kaarilista) haluttuun (FILENAME) tiedostoon. -f FILENAME Kaikkia mahdollisia kombinaatioita ei ole välttämättä tarvetta toteuttaa. Varsinkin tulosteita pitäisi olla helppo muokata lisää omatoimisesti, jos ei sellaisenaan kelpaa: mops [options] graph.gml --verbose, v : tulostelee välivaiheista tietoa --out file, -o file : tallentaa tuloksen gml-formaatissa tiedostoon 3.5.3 mps:n algoritmikuvaus Ohjelman rakenne: 6. lataa graafi 7. satunnainen ratkaisu 8. etsi parempi ratkaisu 9. simuloitu jäähdytys 10.tulostus/graafin tallennus Ohjelma käyttää UTAG-kirjaston algoritmeja etsinnässä: -lista luokkien nimistä 3.6 crossing Projektin vaatimuksiin kuuluu toteuttaa vähintään satunnainen risteämäarvon etsiminen graafista. Varsinainen etsintä-algoritmi toteutetaan UTAG-kirjastossa, mutta tämän toiminnon esittelyä varten tehdään lisäksi komentoriviohjelma, joka toimii samalla kirjaston käyttöesimerkkinä. 3.6.1 crossingin prosessikuvaus Ohjelma saa syötteenä tiedostonimen ja toimintaa ohjaavia parametrejä. Tutkittava graafi voidaan joko ladata tiedostosta (gml-, rmf- tai kaarilistamuodossa) tai muodostaa satunnaismenetelmällä. 17
Ohjelma laskee ja tulostaa löytämänsä graafin risteämäarvon. Lisäksi on mahdollista tallentaa löydettyä risteämäarvoa vastaava graafin esitys koordinaatteineen. 3.6.2 crossingin liittymäkuvaus Komentorivikomento, parametrien esittely. 3.6.3 crossingin algoritmikuvaus 1. lataa graafi 2. a/ graafin risteämäarvon laskeminen b/ graafin risteämäarvon laskeminen ja koordinaattien määrittäminen ladattuun graafiin 3. risteämäarvon tulostus/graafin tallennus 3.7 Ohjelmiston käyttöliittymän kuvaus Tässä luvussa käydään läpi ohjelmiston ulkoiset liittymät. 3.7.1 Liittymät ulkoisiin laitteisiin Ohjelmistolla ei ole liittymiä ulkoisiin tietokoneisiin tai laitteisiin. 3.7.2 Ulkoiset systeemiliittymät Ohjelmisto hyödyntää ulkoisen GTL-graafikirjaston versiota 0.3.3. Kyseinen kirjasto tarjoaa arkkitehtuureja graafien, solmujen ja kaarien käsittelyyn. GTL toimii pohjana oman UTAGkirjaston toteuttamisessa. Näiden kahden kirjaston välinen kommunikointi on tarkoitus dokumentoida hyvin, jotta tulevaisuudessa GTL:n korvaaminen jollain muulla toteutuksella olisi suhteellisen vaivatonta. GTL on oltava asennettuna järjestelmään ennen ohjelmiston käynnistämistä. 4 Käyttäjän käyttöliittymän suunnitelma Tässä luvussa esittelemme ohjelmiston käyttöliittymän käyttäjän näkökulmasta. 18
4.1 Käyttäjän käyttöliittymän kuvaus Ohjelmistoa voidaan kuvata parhaiten sanalla arkkitehtuuri. Sen tarkoituksena on tarjota työkaluja graafiohjelmistojen tarpeisiin. Oletuksena on, että käyttäjällä on valmiudet hyödyntää arkkitehtuuria omassa ohjelmassaan. Näin ollen erityisen käyttöliittymän toteuttaminen ei tässä yhteydessä ole ensisijaista. Projektissa valmistattavat sovellukset tulee toimimaan komentorivipohjaisesti. Käyttäjän tulee käynnistyksen yhteydessä antaa joko ladattavan graafitiedoston nimi tai vaihtoehtoisesti määriteltävä satunnaisen graafin generointi. Lisäksi parametrien avulla tulee määritellä graafista laskettava ominaisuus sekä vaihtoehtoisten algoritmien kohdalla valittava haluttu algoritmi. Ohjelma palauttaa ajon tulokset komentoriville. Haluttaessa generoitu graafi voidaan tallentaa halutussa formaatissa tiedostoon. 5 Rajoitteet Rajoitteita toteutukselle asettavat hyödyntämämme GTL-kirjaston toteutukset. GTL:n käyttämät tietorakenteet eivät välttämättä ole tehokkaimpia mahdollisia, mutta niiden uusiksi kirjoittaminen olisi varsin hankalaa ja aikaa vievää. Joudumme käyttämään GTL:stä versiota 0.3.3, joka on julkaistu vuonna 2000. Kyseinen versio on viimeinen vapaasti saatavissa oleva. Uudemmissa ja kaupallisissa versioissa on korjattu 0.3.3:ssa ilmenneitä virheitä. Onkin luultavaa, että tulemme jossain vaiheessa törmäämään GTL:n virheistä aiheutuviin ongelmiin. Näiden virheiden käsittely saattaa muodostua työlääksi, mutta testauksen avulla niiden paikallistamisen ja korjaamisen ei tulisi olla mahdotonta. 6 Testausasiat Tarkat testistrategiat ovat testaussuunnitelmassa. Dokumentin löytää osoitteesta http://www.uta.fi/~jr69996/crossing/raportit.html. Seuraavassa on vain lyhyet yhteenvedot. 19
6.1 Testiluokat Testauksessa toteutamme seuraavan tyyppisiä testejä: Yksikkötestaus. Yksikkötestauksessa testaamme vain yksittäisiä luokkia (Algorithm, Graph, Node, Edge ja FileIO). Yksikkötestit ovat automatisoituja ja ne ajetaan noin kerran viikossa. Integrointitestaus. Integrointitestausta tarvitaan esimerkiksi, kun rupeamme testaamaan eri komponenttien yhteensopivuutta. Hyväksymistestaus. Hyväksymistestauksessa pyrimme saamaan algoritmien tehokkuuden samalle tasolle kuin apptopinv-ohjelmassa. Tehokkuusrajoina käytämme Timo Porasen väitöskirjasta löytyviä arvoja, joista osa löytyy liitteinä (7.3 ja 7.4) tästäkin dokumentista. Järjestelmätestaus. Viimeisen vaiheen testauksessa testaamme esimerkkiohjelmia, joita käytetään mops:in ja mps:n laskemiseen. Lisäksi tässä vaiheessa tutkimme käytettävyyttä. Tämän kappaleen asioista löytyvät tarkemmat selostukset testaussuunnitelman luvuista 2.2 ja 3.2. 6.2 Tehokkuusrajat Katso liitteet 7.3 ja 7.4. 6.3 Kriittisten komponenttien tunnistaminen Testauksen kannalta kriittisimmät komponentit ovat ehdottomasti Graph-, Node- ja Edgeluokat. Näiden toiminnallisuus on mukana kaikissa algoritmeissa. Jos näihin luokkiin jää virheitä, niin melko todennäköisesti graafiin käsittelyä varten tehdyt algoritmit eivät toimi ollenkaan tai toimivat virheellisesti. 7 Liitteet 7.1 Paketointi- ja asennusasiat GTL, josta UTAG on riippuvainen, tullaan paketoimaan ja jakelemaan erikseen. Levitysmuotoa ja tapaa kontrolloi pääsääntöisesti ohjelman lisenssien rajoitukset. 20
UTAG:tä tullaan levittämään kahdessa eri paketissa. Ensimmäisessä paketissa on esikäännetty Windows-versio, joka sisältää UTAG:n dynaamisen kirjaston (DLL) ja tarvittavat otsikkotiedostot. Tämän lisäksi paketista löytyvät projektin esimerkkiohjelmat mops ja mps käynnistettävinä ohjelmina. Toinen paketti sisältää UTAG:n lähdekoodit, MS Visual C++ -projektitiedostot ja tarvittavat tiedostot ohjelman kääntämiseen ja asentamiseen Linux-käyttöjärjestelmään. Kirjaston saa käännettyä Windows käyttöjärjestelmälle käyttämällä edellä mainittua VC++:n projektitiedostoa. Linux-asennusta varten löytyy autoconf- ja automake-asetustiedostot, jotta asennus toimisi tyypilliseen kolmen komennon tyyliin "./configure; make; make install". Lähdekoodipaketti sisältää niin ikään mps- ja mops-ohjelmien lähdekoodin, projektin yksikkötestit sekä muiden esimerkkiohjelmien lähdekoodit. Molemmat paketit sisältävät myös UTAG:n kattavan dokumentaation. 7.2 MPS-suoritusarvoja Seuraavissa taulukoissa on CA-, CA1- ja CA2-algoritmien suoritusarvoja mps-tapauksessa. Taulukoissa on eräitä graafeja ja näille arvot. Taulukot ovat peräisin Timo Porasen väitöskirjasta (sivut 119-121). Taulukoissa ensimmäisellä sarakkeella on graafin nimi. Suoritusarvoista ensimmäisenä on aika, jota seuraavat huonoin tapaus, keskiarvo ja paras tapaus maksimaaliselle alitasograafille. 21
CA ave t. worst ave best cimi-g1 0,001 11 11 11 cimi-g2 0,001 86 86,82 88 cimi-g3 0,002 37 37,79 38 cimi-g4 0,001 13 13 13 cimi-g5 0,002 58 58,77 59 cimi-g6 0,002 42 42 42 g10 0,001 34 35,21 36 g11 0,001 34 35,21 36 g12 0,002 34 35,07 36 g13 0,004 71 72,4 73 g14 0,006 72 72,64 73 g15 0,008 72 72,72 73 g16 0,009 134 135,72 137 g17 0,012 143 144,56 147 g18 0,011 144 146 147 g19 0,018 214 216,04 218 CA1 ave t. worst ave best cimi-g1 0,001 13 13 13 cimi-g2 0,002 114 116,18 117 cimi-g3 0,002 49 49 49 cimi-g4 0,001 14 15,75 16 cimi-g5 0,002 73 73 73 cimi-g6 0,001 42 42 42 g10 0,001 46 46,95 47 g11 0,002 46 46,96 47 g12 0,002 46 46,98 47 g13 0,006 95 96,76 97 g14 0,006 96 96 96 g15 0,007 97 97 97 g16 0,009 155 158,52 162 g17 0,012 187 189,88 194 g18 0,013 192 194,24 197 g19 0,019 262 268,44 274 22
CA2 ave t. worst ave best cimi-g1 0,001 13 13 13 cimi-g2 0,002 112 115,96 117 cimi-g3 0,002 49 49 49 cimi-g4 0,001 14 15,7 16 cimi-g5 0,002 73 73 73 cimi-g6 0,002 42 42 42 g10 0,002 46 46,94 47 g11 0,002 46 46,89 47 g12 0,001 46 46,84 47 g13 0,005 96 96,8 97 g14 0,006 96 96,96 97 g15 0,007 96 96,96 97 g16 0,008 158 163,32 167 g17 0,013 191 192,56 196 g18 0,015 193 194,68 197 g19 0,019 269 277,08 285 7.3 MOPS-suoritusarvoja Seuraavissa taulukoissa on CA- ja CA1-algoritmien suoritusarvoja mops-tapauksessa. Taulukoissa on eräitä graafeja ja näille arvot. Taulukot ovat peräisin Timo Porasen väitöskirjasta (sivu 129). Taulukoissa ensimmäisellä sarakkeella on graafin nimi. Suoritusarvoista ensimmäisenä on aika, jota seuraavat huonoin tapaus, keskiarvo ja paras tapaus maksimaaliselle ulkoalitasograafille. CA ave t. worst ave best o100.1 0,009 140 142,92 144 o100.2 0,012 140 141,96 144 o100.3 0,024 140 143,04 145 o100.4 0,016 142 143,36 145 o100.5 0,023 142 144,8 147 o200.1 0,016 288 290,2 292 o200.2 0,022 289 290,52 292 o200.3 0,025 285 288,84 291 o200.4 0,028 284 286,56 289 o200.5 0,032 286 288,56 291 23
CA1 ave t. worst ave best o100.1 0,010 191 193,36 196 o100.2 0,012 186 190,4 194 o100.3 0,012 179 187,08 194 o100.4 0,016 184 189,04 195 o100.5 0,020 188 191,24 194 o200.1 0,014 396 396,52 397 o200.2 0,022 390 393,56 397 o200.3 0,024 379 387,36 396 o200.4 0,026 372 383,36 391 o200.5 0,030 372 380,6 394 7.4 Versiohistoria Päivämäärä: Versio: Tekijät: Muutokset: 04.03. 2005 0.8.0 Timo Nummenmaa Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått 12.02. 2005 1.0.0 Aki Mäkinen Jussi Rantala Rami Saarinen Johdantoa muokattu vastaamaan toteutussuunitelmaa, lukua 3.1.1 lähes kokonaan uusittu (vain luvun alku ja kuva 3 säilynyt ennallaan), simuloidun jäähdytyksen parametreja muutettu (mops: 3.4.2; mps: 3.5.2), muutettu parametri -f1:n -frmf:ksi, hieman muokattu lukujen 3.5.1 ja 3.5.2 1. sekä 2. kappaletta, toinen 3.6.2 muutettu 3.6.3:ksi, versiohistoria + muutamia selvennöksejä ja kirjoitusvirheitä 24