Lmodels. Tekninen määrittely. Ryhmä Rajoitteiset

Transkriptio

1 Teknillinen korkeakoulu T Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija Lmodels Tekninen määrittely Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset Tuomas Luttinen Ensimmäinen alustava versio Tuomas Luttinen Enemmän sisältöä rungon päälle. Tätä iteraatiota koskemattomat otsikot on poistettu Tuomas Luttinen Lisäys translaattorin toiminnan kuvaukseen: semanttinen analyysi, hylätyt ratkaisut mukaan Tuomas Luttinen Palautteiden perusteella uuteen pohjaan muokattu versio Jouni Karppinen & Mitro Kuha Dokumentti tarkastettu ja korjattu PP-vaiheen palautusta varten Tuomas Luttinen Edelleen kehitetty versio ensimmäistä toteutusiteraatiota varten Tuomas Luttinen Ensimmäisen toteutusiteraation lopullinen versio Jouni Karppinen & Mitro Kuha Dokumentti tarkastettu ja korjattu I1-vaiheen palautusta varten.

2 Sisällysluettelo 1 Johdanto Tarkoitus ja kattavuus Tuote ja ympäristö Termit ja määritelmät Järjestelmän yleiskuvaus Sovellusalueen kuvaus Järjestelmän liittyminen ympäristöönsä Laitteistoympäristö Ohjelmistoympäristö Toteutuksen keskeiset reunaehdot Arkkitehtuurin kuvaus Suunnitteluperiaatteet Ohjelmistoarkkitehtuuri Moduulien välinen kommunikaatio Järjestelmän pakettirakenne Virheenkäsittely Moduulikuvaukset Nodes Solver Formats Processors Controller Server Client Util Muut luokat Hylätyt ratkaisut Kääntäjän tuottamistyökalut Lineaarinen ratkaisija Järjestelmän arkkitehtuuri päätasolla...17

3 1 Johdanto 1.1 Tarkoitus ja kattavuus Tämä dokumentti on Teknillisen korkeakoulun kurssille T Tietojenkäsittelyopin ohjelmatyö harjoitustyönä tehtävän lineaaristen rajoitteiden tyydyttämistehtävän ratkaisijan tekninen määrittely. Dokumentin ensisijainen tarkoitus on määrittää ja kuvata vaatimusmäärittelyssä esitettyjen toiminnallisuuksien tekninen toteutustapa ja toisekseen täydentää toiminnallista määrittelyä teknisestä näkökulmasta. Näin ollen dokumentti on suunnattu järjestelmän toteuttajille. Toisaalta se on tarkoitettu myös asiakkaan ja kurssin henkilökunnan arvioitavaksi. 1.2 Tuote ja ympäristö Tuotteen nimi on Lmodels. Se on lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija. Tuote tulee toimimaan verkkoyhteyden tarjoavassa tietokoneessa, jossa on Javavirtuaalikone. 1.3 Termit ja määritelmät Seuraavassa taulukossa on selitetty lyhyesti erikoistermistö, jota käytetään tämän asiakirjan eri kohdissa. Vaatimusmäärittelyssä esitettyjen termien ja määritelmien oletetaan olevan tuttuja lukijalle. Termi Määrittely GLPK (GNU Linear Programming Kit) GNU-lisenssin alla jaettava lineaaristen ongelmien ratkaisija. Java-virtuaalikone Jäsennyspuu Käännettyä Java-koodia sisällään ajava prosessi, joka tarjoaa Javasovellukselle kielen vaatimat palvelut, kuten roskankeruun. Eri alustoille tehdyt virtuaalikoneet mahdollistavat Java-sovellusten ajamisen eri ympäristöissä. Kielen terminaaleista ja nonterminaaleista muodostuva tietorakenne, jossa nonterminaalit sisältävät toisia nonterminaaleja ja puun lehdiksi jääviä terminaaleja. Jäsentäjä Muodostaa selaajalta syötteenään saamista terminaaleista nonterminaalien muodostaman jäsennyspuun, joka kuvaa annetun syötteen rakenteen. lp_solve Javalla toteutettu lineaaristen ongelmien ratkaisija. 1

4 Termi LP-kieli Määrittely Lineaaristen mallien määrittelyyn käytettävä kieli, jota esim. GLPK hyväksyy syötteenään. Open Source Ohjelmistoja, joiden lähdekoodi on vapaasti saatavilla ja muokattavissa ja jotka ovat muokattuinekin lähdekoodeineen vapaasti käytettävissä ja eteenpäin levitettävissä. RMI-rajapinta (Remote Method Invocation) Tämän rajapinnan avulla yhdessä Java-virtuaalikoneessa sijaitseva olio voi kutsua toisessa virtuaalikoneessa sijaitsevan olion metodia. Virtuaalikoneet voivat sijaita vaikka fyysisesti eri koneissa. Selaaja Servlet Tomcat Muodostaa tekstipohjaisesta syötteestä säännöllisten lausekkeiden avulla kielen syntaksin mukaisia terminaaleja. Tekniikka tehdä Java-sovellutuksia, jotka vastaavat HTTP-pyyntöihin interaktiivisesti muodostaen WWW-sivuja pyynnön mukana välitettyjen parametrien mukaan. Palvelinohjelmisto, joka tarjoaa servleteille sopivan ajoympäristön. UML (Universal ling Language) Ohjelmistojen mallintamiseen käytettäviä kaaviotyyppejä määrittelevä kieli. Taulukko 1: Termit ja määritelmät. 2

5 2 Järjestelmän yleiskuvaus 2.1 Sovellusalueen kuvaus Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisijana Lmodels pyrkii löytämään ratkaisun malliin annettujen rajoitteiden vallitessa. Mikäli ratkaisu on olemassa, niin käyttäjälle annetaan mahdollisimman tiukat rajat, joiden sisältä kaikki mahdolliset ratkaisut löytyvät, sekä yksi yksiselitteinen ratkaisu. 2.2 Järjestelmän liittyminen ympäristöönsä Lmodels-järjestelmä koostuu palvelinohjelmasta, asiakasohjelmasta sekä komentorivityökalusta, joita ajetaan itsenäisinä kokonaisuuksina. Asiakasohjelma on riippuvainen palvelinohjelmasta, joka kuitenkaan itsenäisenä Java-ohjelmana ei ole sidottu tässä toteutuksessa tehtävään asiakasohjelmaan käyttöliittymineen, vaan sen tarjoamaa RMI-rajapintaa voivat yhtä hyvin hyödyntää ulkopuoliset ohjelmistot, jotka näin voivat käyttää sen tarjoamaa palvelua. 2.3 Laitteistoympäristö Lmodels ei aseta mitään erityisiä vaatimuksia sitä ajavan tietokoneen laitteistolle. Suorituskykyinen kone suurella muistilla on kuitenkin suositeltava, sillä ongelmakenttä, jota Lmodels:lla pyritään ratkaisemaan, on laskennallisesti kompleksinen ongelma. Ajoaika riippuu suuresti mallin koosta ja monimutkaisuudesta, koneen prosessoritehosta ja käytettävissä olevan muistin määrästä. Pienet ja yksinkertaiset mallit hoituvat nopeasti, kun taas suuret tai monimutkaiset mallit voivat viedä paljon aikaa tehokkaallakin koneella. 2.4 Ohjelmistoympäristö Lmodels-järjestelmän ajoa varten tarvitaan Java-virtuaalikone ja GLPK-ratkaisija. Lmodels:n asentamiseksi tarvitaan näin ollen joko C-kääntäjä GLPK:n kääntämiseksi tai valmiiksi käännetty GLPK. Haluttaessa käyttää mukana tulevaa asiakasohjelmaa käyttöliittymineen täytyy asentaa myös Java-servlettien ajon mahdollistava J2EE -standardia tukeva servletajoympäristö, koska käyttöliittymä toteutetaan Java-servletteinä. Kyseisenä palvelinohjelmistona tässä projektissa käytetään Tomcat:ia sen ilmaisuuden vuoksi. Java-kielestä käytetään versiota Ohjelmisto ei aseta rajoitteita käyttöjärjestelmän suhteen, mutta projektiryhmän tarjoama tuki toimii parhaiten Linuxalustalle, sillä kehitystyö tullaan tekemään pääasiallisesti sillä. 2.5 Toteutuksen keskeiset reunaehdot Ohjelmiston toteutuksessa käytetään vain ilmaisia, jos mahdollista Open Source, ohjelmistoja. Projektin dokumentit ovat suomenkielisiä, mutta itse ohjelmakoodi ja koodin kommentit ovat englanninkielisiä. Käyttöohje kirjoitetaan englanniksi. 3

6 3 Arkkitehtuurin kuvaus 3.1 Suunnitteluperiaatteet Järjestelmän toteutuskieli on Java useammastakin syystä, joista ensimmäinen on asiakkaan vaatimus. Lisäksi ryhmän jäsenet ovat tottuneet työskentelemään tällä kielellä, sitä tuetaan useassa ympäristössä, sille löytyy laajat valmiskirjastot sekä tämän projektin vaatimia kääntäjiin liittyviä työkaluja jäsentäjän automatisoituun tekemiseen. Järjestelmään liittyvä käyttöliittymä toteutetaan Java-servletteinä ja HTML-kieltä käyttäen. Vaikka järjestelmässä on mukana käyttöliittymä, niin tällä kertaa suunnittelun painopiste ja sitä eteenpäin ajava voima on teknisellä puolella. Käyttöliittymä on nimittäin tarkoitettu lähinnä testaamiseen, ja pääkäyttö järjestelmälle tulee olemaan osana integroitua suurempaa järjestelmää, jolloin Lmodels:n käyttäjiä ovat toiset ohjelmistojärjestelmät. Järjestelmä toteutetaan käyttäen oliopohjaista mallinnusta ja erilaisia UML-kaavioita eri osien mallintamiseen. Koska koodin toteutuskielenä on englanti, niin kaavioiden kielikin on näin ollen englanti. Eri komponentteihin viitataan pääsääntöisesti kuitenkin tämän dokumentin kielellä eli suomeksi, joten tätä tapaa käytettäessä on kaavioissa esiintyvä englanninkielinen nimi laitettu sulkuihin suomalaisen termin perään, mikäli sitä ei ole saatu liitettyä kontekstiin jouhevasti muulla tavoin. 3.2 Ohjelmistoarkkitehtuuri Yleistason kuva Lmodels-järjestelmästä on esitetty seuraavassa kaaviossa. formats CLIClient WWW client client server controller processors model nodes solver Kaavio 1: Lmodels-järjestelmä. Käyttäjällä on siis kaksi tapaa käyttää järjestelmää, joko paikallisesti komentorivikäyttöliittymällä tai verkon yli WWW-käyttöliittymällä. Molemmissa tapauksissa järjestelmän keskuksena toimii kontrolleri (controller), joka sisältää järjestelmän toimintalogiikan ja joka tuottaa vastaukset käyttäjän tekemiin kyselyihin. Seuraavassa sekvenssikaaviossa on esitettynä esimerkki, jossa Lmodels:ia käytetään komentorivityökalun avulla lineaarisen ongelman ratkaisuun. Komentoriviltä käynnistetään komentorivityökalu (CLIClient), joka käynnistää itselleen uuden kontrollerin (controller), jolle annetaan metodikutsun argumentteina ongelman malli tekstimuodossa ja kiinnitetyt muuttujat arvoineen. Kontrollerin tehtävänä on nyt päätellä mitä vaiheita tarvitaan mallin käsittelyyn ennen kuin se voidaan toimittaa varsinaiselle ratkaisimelle ratkaistavaksi. 4

7 Processor Format :CLIClient controller:controller processor:cnfnormaliser solver:glpksolver main(args[]) create() parser:lmformat :SolverFactory solversolution:=solve(text, limits) create() model:=parse(text) create() model:=processexpr(model) solver:=getsolver(glpk) create() solversolution:=solve(model, limits) Kaavio 2: Sekvenssikaavio komentorivityökalusta. Tässä tapauksessa malli on tekstimuodossa ilman, että sitä olisi normalisoitu tai linearisoitu. Siksi kontrolleri käy kaikki askeleet läpi käyttäen lm-muodon jäsentäjää (parser:lmformat) mallin jäsentämiseksi, CNF-muodon normalisoijaa (processor:cnfnormaliser) normalisointiin ja lopuksi ratkaisijatehdasta (SolverFactory) tuottamaan sopivan ratkaisijainstanssin, joka etsii mahdolliset ratkaisut annettuun ongelmaan. Tekniseltä kannalta kontrollerin ohjaamien moduulien voidaan katsoa muodostavan kääntäjän alkupuolen mukaisen selkeän peräkkäisrakenteen, jossa ensimmäinen askel on tekstimuotoisen syötteen jäsennys, minkä jälkeen seuraavat moduulit tekevät erilaisia muutoksia aikaansaatuun jäsennyspuuhun. Linjan viimeisenä oleva moduuli tuottaa jäsennyspuusta taas tekstimuotoista tulostetta. Tämä muoto on esitetty kaaviossa 3. Vasemmalla on esitetty yleinen malli, jossa syöte tuodaan tekstimuodossa sisään jäsentäjälle, sitä käsittelee yksi tai useampi puun käsittelijä (Processor) ja lopuksi se joko kirjoitetaan taas tekstimuodossa tiedostoon tai lähetetään ratkaisijalle (Solver). 5

8 0-x kpl General File String Format Processor Processor Translator Command line tool File LMFormat CNFNormaliser String LPX command line tool File LMFormat CNFNormaliser Lineariser String (Un)Bound vars User Results model Server mode User File String LMFormat CNFNormaliser Linearisator String Format / Solver File User Results model Kaavio 3: Lmodels kääntäjänä. LMFormat File String LPXFormat File String GLPKSolver Kaksi seuraavaa mallia kuvaavat komentorivityökalujen käyttöä ja niissä on abstraktien rajapintojen sijaan käytetty realisoituvia luokkia. Viimeisin esimerkki oikealla kuvaa palvelimen sisällä käytettyä ketjua ongelman saamiseksi ratkaistavaksi. 3.3 Moduulien välinen kommunikaatio Järjestelmässä on kaksi rajapintaa, joiden kohdalla se voidaan hajauttaa useampaan fyysiseen koneeseen ja kommunikaatio toimii verkkorajapinnan yli. Nämä rajapinnat ovat käyttöliittymän käyttämä HTTP-rajapinta selaimen ja servletpalvelimen välillä sekä järjestelmän sisäinen RMI-rajapinta, joka on esitelty seuraavassa kaaviossa. 6

9 Client RemoteClient +connect(): RMIServer +getconnector(): RemoteController <<RMI>> RMIServer starts ServerSolver returns Controller RMIServerImpl +getconnector(): RMIController returns RemoteController <<RMI>> RMIController RMIControllerImpl Controller 1 SimpleController Kaavio 4: RMI-arkkitehtuuri. Luokka ServerSolver käynnistää RMI-prosessin palvelimen puolella ja jää kuuntelemaan pyyntöjä. Asiakasohjelma käynnistyy ja pyytää itselleen asiakastehtaasta (ClientFactory) uuden asiakas-rajapinnan (Client) toteutuksen ja saa itselleen RMI:tä tukevan asiakasolion (RemoteClient). Tämä ottaa yhteyden palvelimeen ja saa itselleen viitteen RMI-palvelimeen (RMIServer), jolta asiakasolio saa viitteen palvelimen kontrolleriin (RMIController), joka tallennetaan asiakaspäässä omaan olioonsa (RemoteController). Tämän jälkeen asiakas voi käyttää oman päänsä kontrolleria (RemoteController) aivan normaaliin tapaan, koska RMI:n toteutus mahdollisine ongelmatilanteineen on upotettu sen sulkeviin luokkiin. Itse työn tekee palvelimen päässä tavallinen kontrolleri (SimpleController), jolle pyynnöt ohjataan RMI-rajapinnan yli. Kuvan keskellä kulkevan jakolinjan yli menevä liikenne voi tapahtua verkon välityksellä kahden eri fyysisen koneen välillä. Tällöin Lmodels voidaan jakaa kahdelle koneelle siten, että toinen näistä koneista ratkoo ongelmia toisen toimiessa palvelimena, joka tarjoaa käyttäjien selaimelle tarpeellisen WWW-palvelun. Integroitaessa Lmodels:ia asiakkaan laajempaan järjestelmään tulee yllä kuvattu RMI-rajapinta olemaan toisten ohjelmakomponenttien käyttöliittymä Lmodels-järjestelmään. 3.4 Järjestelmän pakettirakenne Järjestelmän pakettirakenne on esitetty kaaviossa 5. 7

10 lmodels client server controller model processors formats solver nodes util Kaavio 5: Lmodels:in pakettikaavio. Pakettien riippuvuudet ketjuuntuvat alaspäin vieviksi ketjuiksi ilman silmukoita. Ylimpänä tasona ovat palvelin- (server) ja asiakas- (client) paketit, jotka kommunikoivat kontrollerin (controller) kanssa, joka puolestaan käyttää muista paketeista löytyviä luokkia ja niiden metodeita ratkaistakseen lineaarisia ongelmia. 3.5 Virheenkäsittely Virheenkäsittely Lmodels-järjestelmässä perustuu pakettikohtaisiin poikkeuksiin, joita on yksi kutakin pakettia kohden. Yleisesti kyseisen paketin rajapinta ilmoittaa heittävänsä tämän poikkeuksen ongelmatilanteissa, johon rajapinnan hyödyntäjän tulee varautua. Jokaisesta kerroksesta pyritään tekemään mahdollisimman hyvin alemman kerroksen virheitä sietävä. 8

11 4 Moduulikuvaukset Seuraavissa kappaleissa on esitelty jokaisen paketin sisältö pääkohdittain, sekä mahdollinen rajapinta, jolla paketin sisältämiä luokkia voidaan käyttää. 4.1 Nodes Tämän paketin luokkien tarkoitus on muodostaa jäsennyspuu. Alla on kuvattu paketin luokkarakenne. Expr +getnew(...): Expr BooleanExpr +getnew(...): BooleanExpr FloatExpr +getnew(...): FloatExpr BinaryBooleanExpr Not Comparison BooleanVariable +left: BooleanExpr +Right: BooleanExpr +getnew(booleanexpr,booleanexpr) +leftexpr +getnew(booleanexpr) +left: FloatExpr +right: FloatExpr +getnew(floatexpr,floatexpr) +name: String +negated: Boolean BooleanConstant And Or Xor Equiv Impl EQ NEQ GT LT GE LE Sub Luokasta ei oteta instansseja, getnew palauttaa AINA toisen luokan instanssin. BinaryFloatExpr +getnew(floatexpr,floatexpr,) FloatVariable +mul: double +name: String Add Sub Mul Div UMinus +getnew(floatexpr) FloatConstant Kaavio 6: Paketin nodes luokkakaavio. Erityistä huomiota kannattaa kiinnittää siihen, että läheskään kaikista operaattoreista ei tulla luomaan oman luokkansa instansseja. Niiden sijaan käytetään toisten operaattoriluokkien instansseja, joilla saadaan sama asia ilmaistua toisella samanarvoisella tavalla. Tämän ansiosta lopullisen puun käsittelyssä selvitään vähemmällä vaivalla, koska erilaisia operaattoreita on rajoitetummin. Seuraavassa taulukossa on kuvattu puun muodostamisen apuna käytetyt operaattoreiden korvaavuudet. 9

12 Luokka Lause Korvattu lause Xor a xor b ( a and not b) or (not a and b) Equiv a equiv b not(a) xor b Implies a implies b not(a) or b Sub j - k j + -1*k Uminus -k -1 * k Div k/ * k Taulukko 2: Korvattavat operaattorit korvaavuuksineen. Alla olevassa kaaviossa on vielä kuvattuna esimerkkinä eräs jäsennyspuu konjunktiivisessa normaalimuodossa. Expr Tree in CNF and or and 3.1*A >= not K or or P NOT p and or 3*B 12 + >= 0 or K not T 3*A + K not T 3*B *D Kaavio 7: Jäsennyspuu konjunktiivisessa normaalimuodossa Seuraavassa kaaviossa on esitetty pakettien model ja solver sisältö luokittain. 10

13 model 1 1 Vmap Solution solver SolverFactory solvable: boolean 1 1 SolverSolution cputime: int modelsize: int Solver AbstractSolver * Variable 1..* VariableSolution SolverEvent GLPKSolver VariableLimits SolverListener Kaavio 8: Pakettien model ja solver luokkakaavio. Paketin model pääluokka on mallin () sisältävä luokka, joka sisältää muuttujien määritelmät omassa luokassaan (Vmap). Tämän luokan sisäinen toteutus on linkitetty hajautustaulu, johon on säilötty muuttujia omassa luokassaan (Variable). Malli yhdessä kiinnitettyjen muuttujien (VariableLimits) kanssa muodostaa ongelman. Sille on olemassa ratkaisu (Solution), joka puolestaan sisältää ongelman jokaiselle muuttujalle ratkaisun (VariableSolution), joka puolestaan sisältää muuttujan rajat ja käyvän ratkaisun, mikäli sellainen löydettiin. 4.3 Solver Paketissa solver on ratkaisijaan liittyviä luokkia. Seuraavassa taulukossa on esitelty paketin rajapinnat. Rajapinta Merkitys Solver Ratkaisijan määrittelevä rajapinta. Sisältää metodit lineaarisen ongelman ratkaisemiseksi sekä kuuntelijan (SolverListener) lisäämiseen ja poistamiseen. SolverListener Kuuntelija, joka seuraa ratkaisijan työn edistymistä. Ratkaisija tiedottaa edistymisestään tapahtumilla (SolverEvent). Taulukko 3: Rajapinnat solver-paketissa. Erilaisten ratkaisijatyyppien tuottamiseksi paketissa on tehdasluokka (SolverFactory), joka luo ratkaisijoita annetun tekstitunnisteen mukaan. Muita paketin luokkia ovat tapahtuma (SolverEvent), jolla tiedotetaan ratkaisijan edistymisestä, sekä SolverSolution, joka sisältää ongelman ratkaisun sekä tähän ratkaisuun liittyvää oheistietoa, kuten käytetyn koneajan ja mallin koon. 11

14 4.4 Formats Seuraavassa kaaviossa on esitetty tämän paketin luokkarakenne. formats Format parse(string): format(): String LMFormat LPXFormat Kaavio 9: Paketin formats luokkakaavio. Tämä paketti sisältää seuraavan rajapinnan ja sen toteuttavia luokkia. Rajapinta Merkitys Format Muotoilijan (Format) määrittelevä rajapinta. Sisältää metodit lineaarisen mallin muodostamiseen tekstisyötteestä sekä lineaarisen mallin tulostamiseksi tekstimuotoon. Taulukko 4: Rajapinta formats-paketissa. Rajapinnan toteutusluokkia tehdään kaksi kappaletta. Näistä ensimmäinen käsittelee määrittelemäämme lm-kieltä ja toinen lineaaristen mallien kuvaamiseen yleisesti käytettyä lpx-kieltä. 4.5 Processors Kaaviossa 10 on esitetty tämän paketin luokkarakenne. Tämä paketti sisältää edellisen paketin tavoin yhden rajapinnan sekä sen toteuttavia luokkia. 12

15 processors Processor +process(m:): Lineariser Normaliser CNFNormaliser DNFNormaliser Kaavio 10: Paketin processors luokkakaavio. Rajapinta Processor Merkitys Mallin prosessoijan (Processor) määrittelevä rajapinta. Tämän rajapinnan ainoa metodi on process, joka ottaa sisäänsä argumenttina annetun mallin ja palauttaa uuden prosessoidun mallin. Taulukko 5: Rajapinta processors-paketissa. Toteuttavia luokkia on processors-paketissa useampia, ja ne jakautuvat kahteen lajiin: mallin linearisoijaan (Lineariser) ja normalisoijiin. Jälkimmäisiä on yksi isäluokka (Normaliser) ja kaksi toteutusta kahdelle eri normaalimuodolle (CNFNormaliser, DNFNormaliser). 4.6 Controller Seuraavassa kaaviossa on esitetty tämän paketin luokkarakenne. 13

16 controller Controller SimpleController Tämä paketti sisältää edellisten pakettien tavoin yhden rajapinnan sekä sen toteuttavan luokan. Tämän rajapinnan toteuttava luokka on myös paketissa client liittyen kontrollerin käyttöön RMI-rajapinnan yli. Rajapinta Merkitys Controller Rajapinta Controller määrittelee metodit, joilla mallia voidaan järjestelmän ulkopuolelta käsitellä. Taulukko 6: Rajapinta controller-paketissa. Yksinkertainen kontrolleri (SimpleController) on rajapinnan ainoa täysi toteutus, joka sisältää tarpeellisen logiikan mallin vaatiman käsittelyn selvittämiseen annettujen parametrien ja mallin itsensä avulla. Muiden saman rajapinnan toteuttavien luokkien toiminta palautuu tämän luokan metodien kutsumiseen. 4.7 Server Kaavio 11: Paketin controller luokkakaavio. Seuraavassa kaaviossa on esitetty tämän paketin luokkarakenne. server RMIServer RMIController RMIServerImpl +getconnector(): RMIController RMIControllerImpl Kaavio 12: Paketin server luokkakaavio. Paketti server sisältää RMI-rajapinnan palvelimen puolen toteutuksen sekä rajapinnat 14

17 näiden toteutusten viitteen toimittamiseksi RMI-yhteyden yli, jotta metodikutsut voidaan välittää toiseen koneeseen. Rajapinta Merkitys RMIServer Rajapinta RMIServer määrittelee RMI-rajapintaa kuuntelevan palvelimen ja sen metodin getconnector, jolla saadaan toimitettua viite kontrollerista RMI-rajapinnan toiselle puolelle. RMIController Taulukko 7: Rajapinnat server-paketissa. Rajapinta RMIController määrittelee samat metodit kuin rajapinta Controller mallin käsittelemiseksi RMI-rajapinnan yli. Palvelimen toteutus (RMIServerImpl) on siis konkreettinen olio, joka toimii RMIpalvelimena. Kontrollerin RMI-toteutus (RMIControllerImpl) puolestaan käyttää suoraan tavallista kontrolleria (SimpleController) toteuttaakseen mallin käsittelyn metodit. 4.8 Client client ClientFactory +getclient(): Client creates Client LocalClient +getconnector(): Controller RemoteClient +connect(address:string) +getconnector(): Controller returns returns RemoteController controller Controller SimpleController Kaavio 13: Pakettien client ja controller luokkakaavio. 15

18 Kaaviossa 13 on esitetty tämän paketin luokkarakenne ja rakenteen ymmärtämisen kannalta tarpeellisia luokkia myös controller-paketista. Seuraava taulukko esittelee tämän paketin sisältämän rajapinnan. Rajapinta Client Merkitys Rajapinta Client määrittelee asiakkaan metodit, joilla otetaan yhteys palvelimeen ja saadaan viite kontrolleriin. Taulukko 8: Rajapinta client-paketissa. Paketti sisältää tehdasluokan (ClientFactory), jolla luodaan asiakas (Client) tilanteen mukaan. Kyseisen rajapinnan toteuttavista luokista paikallinen asiakas (LocalClient) toteuttaa vain metodin getconnector, jolla se luo uuden tavallisen kontrollerin (SimpleController). Etäasiakas (RemoteClient) toteuttaa metodin connect, jolla luodaan yhteys palvelimeen. Tämän luokan metodi getconnector pyytää palvelimen puolelta viitteen RMI-kontrolleriin (RMIController), joka suljetaan etäkontrolleriluokan (RemoteController) olioon RMI-yhteyden piilottamiseksi ulkopuoliselta käyttäjältä. 4.9 Util Paketti util sisältää yleisesti hyödyllisiä apuluokkia metodeineen, kuten tiedoston käsittelijän luku- ja kirjoitusoperaatioineen Muut luokat Yllämainittujen alipakettien lisäksi paketti lmodels sisältää kolme Java-luokkaa, jotka ovat main-metodin sisältävinä luokkina tarkoitettu käynnistämään järjestelmä eri toimintamuotoihin eli komentorivityökaluna, palvelimena ja asiakasohjelmana. 16

19 5 Hylätyt ratkaisut Projektin päästyä toteutuksen tasolle on eteen tullut jo kohtuullinen määrä valintatilanteita, joissa on otettu kantaa teknisen toteutuksen moniin kohtiin alkaen kääntäjän tuottamiseen käytettävistä työkaluista aina kokonaistason arkkitehtuuriin. 5.1 Kääntäjän tuottamistyökalut Ensimmäisenä asiana on translaattorin luomisessa apuna käytettävät kääntäjän tuottamistyökalut, joiksi päätettiin ottaa CUP ja JLex. Näiden vaihtoehtona oli kehittyneempi, myös itsensä Sunin tukema Open Source työkalu JavaCC, joka on sekä jäsentäjän että selaimen generoiva työkalu. Emme kuitenkaan valinneet tätä mentorimmekin suosittelemaa työkalua, vaan käytämme jäsentäjän generointiin CUP:ia ja selaimen generointiin JLex:iä, koska asiakkaamme oli vanhempien työkalujen puolella ja ryhmällä itsellään on kokemusta niiden käytöstä päinvastoin kuin JavaCC:n kohdalla. 5.2 Lineaarinen ratkaisija Toinen hylkäävä ratkaisu on myös tehty lineaarisen ratkaisijan kohdalla, sillä ratkaisijaksi oli GLPK:n lisäksi tarjolla Javalla toteutettu lp_solve. Vaikka tätä ratkaisua olisi voinut puolustaa toteutuskielen yhtenäisyydellä, niin hylkäämiseen johtaneet seikat veivät voiton. Vaikka lp_solve on toteutettu Javalla, niin se vaikutti tehdyn automaattisesti aikaisemmasta C-toteutuksesta. Myöskään sen ylläpidosta ei ollut minkäänlaisia takeita, sillä sen toteuttamiseen käytetty Java-versiokin oli jo aika vanha. 5.3 Järjestelmän arkkitehtuuri päätasolla Suunnitteluvaiheessa oli esillä suuremmista kokonaisuuksista koostuva arkkitehtuuri järjestelmän toteuttamiseksi. Tästä kuitenkin luovuttiin, koska nämä suuremmat kokonaisuudet koettiin liian raskaiksi ja kömpelöiksi, joten lopullisen arkkitehtuurin kohdalla päädyttiin käyttämään pienemmistä osista koostuvaa ketjua, jonka lisäksi järjestelmässä on erillinen logiikka, joka ohjaa ketjun käyttäytymistä. Tällöin tämä logiikka voi jättää vaikka osan ketjusta pois, mikäli sisään syötetään jo osin käsiteltyä syötettä, kuten esimerkiksi normalisoitu malli. 17