Ylläpitodokumentti

Luokka, joka hoitaa tietokannan kanssa kommunikoinnin. Luokka on toteutettu staattisena kirjastoluokkana, mutta koska se tarvitsee erinäisiä parametreja JDBC-yhteyden muodostamiseen, täytyy ne asettaa setDBServer-metodilla, ennen kuin muita metodeita voidaan käyttää. Metodi asettaa kaikki tarvitavat parametrit staattisiin muuttujiin ja rekisteröi JDBC-ajurin.

Luokka tietokantahakujen tuloksien palauttamiseen. Kopioi jossainmäärin ResultSetin yleistä toiminnallisuutta. Sisältää rivejä ja sarakkeita, joissa tietoa Object-olioina. Tietoja voi hakea joko yksitellen tai muuttamalla koko tuloksen XML:äksi. Tuloksen voi muutta myös DOM-puuksi. Tiedot ovat talletettu sarakkeita vastaaviin vektoreihin. Sarakevektorit taas ovat laitettu hajautustauluun, josta ne saa sarakkeen nimen perusteella.

Konstruktorissa annetaan hakutuloksen sisältävä ResultSet ja taulun nimi, josta tulos saatiin. Luo sarakevektorit ja hajautustaulun. Laskee rivit ja sarakkeet.

Hyvin yksinkertainen luokka, joka vain käyttää DBResult:in toXML-metodia.

Sisältää staattisen filter-metodin, joka uorittaa tuotelistan prosessoinnin tuoteriippuvuuksien ja asiakkaan profiilitietojen perusteella. Varsinaiseen prosessointiin luokka käyttää DependencyCore-luokkaa. Parametreina saatujen DBResult-olioiden muuttamiseen DependencyCoren ymmärtämiksi Item- ja DependencyRule- olioiksi käytetään sisäluokkia ProductFactory ja DependencyFactory. Koska Item on interface, sille on tehty toteutus ProductItem, joka myös on DependencyFilterin sisäluokka. Kun DependencyCore on merkinnyt tuotelistan tuotteet, rakennetaan alkuperäisestä syötteenä annetusta listasta DOM-puu, (DBResultin toDOM-metodilla) joka käydään läpi ja siihen lisätään selectable-tagit DependencyFilterin merkintöjen mukaisesti. Lopuksi DOM-puu muutetaan XML-merkkijonoksi.

Yksinkertainen Item-interfacen toteutus. Sisältää ID:n (id) ja tilan (state).

Sisältää staattisen metodin createProducts, joka muuttaa DBResult-olion ProductItem taulukoksi. Käy yksinkertaisesti läpi kaikki DBResultin rivit ja luo niiden pohjalta ProductItem-olioita. Ainoa DBReultista käytettävä tieto on id, tila alustetaan arvolla YES. Mikäli tapahtuu jokin virhe (esim. DBResult ei sisällä tarvittuja tietoja) kirjoitetaan siitä merkintä lokiin ja palautetaan tyhjä taulukko.

Sisältää staattisen metodin createDependencies, joka muuttaa DBResult-olion DependencyRule-taulukoksi. Käy läpi DBResultin rivit ja luo niiden pohjalta DependencyRule-olioita. Mikäli tapahtuu jokin virhe (esim. DBResult ei sisällä tarvittuja tietoja) kirjoitetaan siitä merkintä lokiin ja palautetaan tyhjä taulukko.

Kuvaa kahden tuotteen välistä riippuvuutta. Tuotteisiin viitataan Object-tyyppisillä tunnisteilla source ja target. Riippuvuuden tyyppi ilmaistaan kokonaisluvulla. Tyyppiä varten on määritelty vakiot TYPE_INCLUDE ja TYPE_EXCLUDE, muun tyyppisiä riippuvuuksia ei ole. Konstruktorissa annetaan tuotteiden tunnisteet ja tyyppi. Mikäli lähde tai kohde ovat samoja tai tyyppi on jokin muu kuin TYPE_INCLUDE tai TYPE_EXCLUDE, tuotetaan IllegalArgumentException. Luokassa on lisäksi aksessorit lähteelle, kohteelle ja tyypille.

Sisältää staattisen metodin processDependencies, joka prosessoi annetun Item-taulukon (available [=tuotelista]) toisen Item-taulukon (selected [=profiilitiedot]) ja näiden välisten riippuvuussuhteiden (dependencies) perusteella.

Available-taulukon Item:ien tilaksi asetetaan joko YES, NO tai MORE seuraavan logiikan mukaan: (Merkitään availablea A:lla ja selectediä S:llä. Itemien a ja b välistä include-sääntöä merkitään a+>b ja exclude-sääntöä a->b)

Jos a kuuluu A:han ja b kuuluu S:ään ja on olemassa sääntö a->b tai b->a, on a:n tila NO. Jos a ja b kuuluvat A:han ja on olemassa sääntö a+>b ja b:n tila on NO, on myös a:n tila NO. Jos a kuuluu A:han ja on olemassa sääntö a+>b ja b:n tila ei ole NO, mikäli se sisältyy A:han, on a:n tila MORE. Muutoin a:n tila on YES.

Metodi käyttää apuna luokkaa ItemNode, jonka avulla muodostetaan available-taulukon alkioista verkko. Jokainen verkon solmu (ItemNode-olio) vastaa yhtä available-taulukon alkiota. Siitä on kaaret niihin solmuihin, jotka tarvitsevat sen (eli on olemassa vastaava include-sääntö). Ajatuksena on ensin luoda verkon solmut (tilaksi alustetaan YES), prosessoida sitten include-säännöt ja lisätä niitä vastaavat verkon kaaret (ja asettaa vastaavien solmujen ja Itemien tilaksi MORE). Lopuksi käsitellään exclude-säännöt. Kun jonkin solmun (ja Itemin) tilaksi asetetaan NO, voidaan nyt käydä rekursiivisesti läpi kaikki sitä tarvitsevat solmut ja asettaa niidenkin tilaksi NO. Rekursio on toteutettu ItemNode-luokassa. Sääntöjen käsittelyn helpottamiseksi available-taulukon Itemejä vastaavat solmut asetetaan ensin hajautustauluun, josta ne löytyvät nopeasti Itemin ID:n avulla. Selected-taulukon Itemeille taas luodaan HashSet, jonka avulla saadaan selville mitkä Itemit sisältyvät selected-taulukkoon.

Luokka helpottamaan riippuvuussuhteiden setvimistä, kuten DependencyCore:n kohdalla kerrottiin. Sisältää yhden Item-olion, sen tilan sekä listan niistä ItemNode-olioista, jotka tarvitsevat tätä (eli verkon kaaret). Konstruktorissa annetaan Item ja sen sekä kyseisen ItemNoden tilaksi asetetaan YES.

Metodi addRequirer lisää yhden ItemNoden tarvitsijoiden listaan.

Metodi setState asettaa ItemNoden ja sen sisältämän Itemin tilan. Mikäli tila on NO, käydään läpi kaikki tarvitsijalistaan merkityt solmut ja kutsutaan niillekkin metodia setState(NO). Kutsua ei kuitenkaan tehdä, jos solmun tila on jo valmiiksi NO. Tämä estää algoritmia jäämästä ikuiseen silmukkaan, mikäli verkko sisältää syklejä. Jotta prosessointi toimisi oikein, ei setStatea saa kutsua arvolla NO ennenkuin kaikki verkon kaaret ovat varmasti asetettu.

Servlet-osajärjestelmä on TAHKO:n keskeisin osajärjestelmä. Se välittää käyttäjän tekemät http-requestit eteenpäin TAHKO:n sisällä. Kaikki kommunikaatio käyttäjän/käyttöliittymän kanssa tapahtuu Servlet-osajärjestelmän välityksellä.

Servlet-osajärjestelmässä on vain yksi luokka: TahkoServlet, joka on aivan tavallinen HttpServlet:in aliluokka. Kuten servletit yleensä, se kuormittaa metodit init(), doGet() ja doPost().

Init() hakee web.xml-tiedostossa määritellyt alkuparametrit (esim. tietokannan nimi, tilapäistiedostojen hakemisto) ja alustaa niiden perusteella Servletin, DBSlaven ja TomcatWrapperin.

doPost() pelkästään delegoi saamansa kutsut doGet() -metodille.

TahkoServletin doGet()-metodi on TAHKO:n sydän. Se käskee käyttäjältä saatujen pyyntöjen perusteella Db-osajärjestelmää tekemään tietokantahakuja, ApacheWrapperia sekä käsittelemään xml-tiedostoja että kääntämään ja suorittamaan JSP-sivuja. Käyttäjälle doGet() palauttaa käyttöliittymä-html -sivuja. doGet()-metodin toteuttaminen oli suoraviivaista suunnitelman perusteella, koska monimutkaisuus on piilotettu muihin osajärjestelmiin.

Tämä on toteutukseltaan yksinkertainen työkaluluokka, joka sisältää vain yhden staattisen funktion. Sitä käytetään muuntamaan profiili-xml PDF-muotoon. Välivaiheena on fo-xml, joka saadaan Profiili-xml:stä xsl-muunnoksen avulla. Muunnokseen käytetään XmlProcessor -luokkaa. Apachen Fop muuntaa näin saadun fo-xml:n PDF:ksi. Virhetilanteessa aiheutetaan PDFProcessingException, joka on TahkoExceptionin aliluokka.

Tämä on toteutukseltaan yksinkertainen työkaluluokka. Sitä käytetään xsl-muunnosten tekemiseen xml-dokumenteille. Ainoan staattisen funktion toteutus sisältää tavanomaisia kutsuja Apachen Xalaniin. Xalanin käytön aikana syntyneet virheet kirjoitetaan tahkon lokiin. Virhetilanteessa aiheutetaan XMLProcessingException, joka on TahkoExceptionin aliluokka.

Tämä luokka kapseloi Apachen Tomcat JSP-koneen TAHKO:n tarkoituksia varten. Tomcatia käytetään tässä luokassa paitsi jsp-sivujen ajamiseen, niin myös niiden kääntämiseen. TomcatWrapper tallettaa jo servleteiksi käännetyt jsp-sivut HashMap:iin, jotta niitä ei joka ajokerralla tarvitsisi kääntää uudestaan (kääntäminen on todella hidas toimenpide). Tällainen Apachen Tomcatin integroiminen osaksi omaa ohjelmaa on monimutkaista verrattuna Fop:n ja Xalanin integrointiin.

Tavallisten alustusten lisäksi konstruktorissa luodaan HashMap, johon talletetaan <servlet,pageId> -pareja sitä mukaa kun JSP-sivuja käännetään.

Translate-funktio kääntää JSP-sivun ja sijoittaa tuloksena saadun servletin HashMap:iin. Tomcatin rakenteesta johtuen tämä on helpommin sanottu kuin tehty. Joudutaan tekemään omat (sisäluokka-) implementaatiot JspCompilationContext, Mangler ja Options -rajapinnoille sekä kirjoittamaan aliluokat JspLoader ja ClassLoader -luokille.

Service-funktio etsii HashMap:sta pageId:tä vastaavan servletin, ja välittää tälle annetun requestin. Jotta Service-metodi voisi palauttaa servletin työn tuloksen Stringinä, se välittää servletille itse tehdyn implementaation HttpServletResponse -rajapinnasta. Tämä implementaatio käyttää apunaan itse tehtyä ServletOutputStream:n aliluokkaa, ja pystyy siten palauttamaan Stringin getResponse() -metodillaan. TAHKO:ssa tämä string on XML-muotoinen, niinsanottu data-xml.

Tahko-järjestelmää voidaan konfiguroida muuttamalla kolmen tyyppisiä XML- ja XSL-tiedostoja. Yksi näistä muutettavista XML-tiedostoista on käyttöliittymä-XML. Käyttöliittymä-XML luo pohjan koko järjestelmän perusrakenteelle; se kertoo, millaisista sivuista järjestelmä koostuu. Näistä "sivuaihioista" muodostetaan HTML-sivuja logiikka-XSL:n logiikkasääntöjen ja käyttöliittymä-XSL:n ulkoasusääntöjen perusteella.

Esimerkkisovelluksen, tarjouskonfiguraattorin, käyttöliittymä-XML sisältää seuraavat elementit, jotka on listassa lueteltu hierarkkisesti rakenteensa perusteella:

Tarjous-XML on senhetkinen tarjous datamuotoisena. Tästä dokumentista muodostetaan XSL-tyylitiedoston avulla HTML-sivu, joka esittää tarjouksen senhetkisen tilanteen.

Esimerkkisovelluksen tarjous-XML sisältää seuraavat elementit, jotka on listassa lueteltu hierarkkisesti rakenteensa perusteella:

XSL-tiedostoissa on yleisiä eri dokumentteihin liittyviä XSL-tageja, jotka on esitelty seuraavassa taulukossa.

Lisäksi Tahko-järjestelmän esimerkkisovelluksen toimintojen toteutuksessa on käytetty selainpään Java-skriptiä. Tämä mahdollistaa ennen kaikkea hintojen nopean laskemisen sitä mukaa, kun asiakas muuttaa jonkin osakomponentin hintaa, tai valitsee uuden tuotteen. Toiminta on paljon nopeampaa, kun välillä ei tarvitse tehdä palvelinkutsuja.

Java-skriptin käyttö ei ole kuitenkaan ollenkaan välttämätöntä rakennettaessa sovelluksia Tahko-järjestelmällä.