Toteutuksen ongelmat

3.3.1 Tyyppiorientoitunut lähestymistapa

Bergqvist käsitteli TOP-jäzjestelmän tehokkuusongelmia väitöskirjansa luvussa 8.5 [Berg87]. Toteutuksen heikkouksina mainitaan seuraavat neljä kohtaa:

1. Järjestelmän toiminta perustui demonien tarkkailemaan viestien välitykseen. Malliin tehtyjen muutosten jälkeen oli löydettävä kaikki sellaiset demonit, joiden laukaisuehto täyttyi muutoksen johdosta. Toteutustavan takia kaikki mallissa olleet demonit jouduttiin käymään läpi jokaisen muutoksen yhteydessä. Usein mallin tehty muutos aiheutti vain muutaman tai jopa ei yhdenkään demonin laukeamisen.

Ratkaisuina esitettiin riippuvuustiedon laskentaa valmiiksi jokaiseen tietämyskomponenttiin. Tässä työssä rakennettiin huomattavasti tehokkaammat mekanismit riippuvuustiedon laskentaan ja johdettujen komponenttien invalidoimiseen. Toteutettuja mekanismeja käsitellään kappaleessa 5.2.

2. Viittaukset mallin komponentteihin oli toteutettu symbolisina tekstiviittauksina.

Tätä ongelmaa käsitellään tarkemmin seuraavassa kappaleessa 3.3.2.

3. Lähetettyjä viestejä vastaavien tulkintojen valitsemiseen tarvittiin Common Lisp- kielen geneeristen funktioiden käsittelymekanismia. Vastaavien mekanismien rakentamisen muilla ohjelmointikielillä arveltiin olevan pitkästyttävää.

4. Keskusmuistissa olevan mallin tallettaminen massamuistilaitteeseen ja lataaminen takaisin keskusmuistiin oli erittäin hidasta. Ongelma koettiin niin suureksi, että se esitettiin väitöskirjassa jatkotutkimusehdotuksena. Mallin tallettamista ja lataamista käsitellään tässä työssä kappaleissa 4.4.4 ja 5.1.6.

Tehokkuusongelmien lisäksi TOP-ytimen tapa ohjata viestejä tietoalkioihin liitetyille tietämystyypeille aiheutti hankaluuksia. Tyyppiorientoituneessa ohjelmoinnissa yhteen tietoalkioon tai instanssiin voitiin liittää useita tietämystyyppej ä. Sovelluksen käyttäytyminen määräytyi tietämyskomponenttien välisen viestienvälityksen perusteella. Kuvassa 8 on esimerkki tietoalkioon Profit liitetyistä neljästä tietämystyypistä. Tyypin Numberlist perusteella voidaan päätellä, että tietoalkion Profit

arvo on lista lukuja. Jokaiselle alkiolle on määritelty tyypin Number-Range mukaiset ylä- ja alarajat. Tietoalkion arvo voidaan esittää käyttöliittymässä tyypin Display able mukaisesti ja sille on annettu tyypin Calculatable aspektiin talletettu laskentasääntö.

VIESTIT TIETÄMYSTYYPIT TIETOALKIO

SIGNAL-QUERY SIGNAL-UPDATE SIGNAL-CALL SIGNAL-DISPLAY

NUMBER-RANGE NUMBERLIST DISPLAYABLE CALCULATABLE

Kuva 8 Esimerkki tietämystyyppien avulla tapahtuvasta viestien tulkinnasta Väitöskirjan [Berg87] määritelmän 3.4 mukaan monityyppisen tietoalkion (multi-type knowledge item) tyypeistä yksi on primäärityyppi ja loput sekundaarityyppejä.

Määritelmän 3.5 mukaan signaalin lähettäminen käynnistää tulkinnan, joka määräytyy signaalin ja vastaanottajien primäärityyppien perusteella. Stratex-järjestelmän käytössä esille tullut ongelma oli, että mitään tietoalkioon liitettyä tyyppiä ei voitu pitää muihin verrattaessa primäärityyppinä. Kuvassa 8 on esitetty neljä signaalia monityyppiselle tietoalkiolle Profit. Signaalia Call vastaava tulkinta on aina tietämystyypissä Calculatable. Muiden signaalien tulkintojen tulisi muodostua useiden tietämystyyppien tulkintojen yhdistelmistä, esimerkiksi signaalin Update tulisi päivittää tietämystyypin Numberlist perusteella varattua lukulistaa ja tarkistettava, että jokainen yksittäinen lukuarvo on tietämystyypin Number-Range määrittelemissä rajoissa. Vastaavasti Z>/5p/äy-signaalin tulkintaan voidaan tarvita tietoa jopa kaikista liitetyistä tietämystyypeistä.

Tulkinnat olivat keskeinen tapa rakentaa asiakaskohtaisen mallin toiminnallisia osia.

Koska viestiä vastaavaa tulkintaa ei oltu määritelty yksikäsitteisesti, jouduttiin viesteihin joskus lisäämään eksplisiittisesti sen tietämystyypin nimi, jonka tulkinta haluttiin suorittaa. Kun tietämystyypin nimi oli kerrottu viestissä, niin riippumatta muista tietämystyypeistä suoritettiin aina lähinnä kohdetyyppiä olleen tietämystyypin tulkinta, jolloin mielivaltaisten tietämystyyppien liittämisellä tietoalkioon ei enää ollut merkitystä. Tällöin ei myöskään voitu hyödyntää väitöskirjassa esitettyjä tyyppiorientoituneen ohjelmoinnin hyötyjä.

TOP-järjestelmän toteutus ei ollut täysin väitöskirjan [Berg87] mukainen. Erityisesti tyyppien periytyminen alaluokille ja instansseille oli toteutettu puutteellisesti. Uusi alaluokka tai instanssi sai luontivaiheen jälkeen käyttöönsä ylemmällä tasolla määritellyt tyypit ikäänkuin oletusarvoina. Mikäli ylemmälle tasolle myöhemmin tehtin muutoksia, eivät kaikki muutokset periytyneetkään alemmille tasoille. Stratex- järjestelmässä seurauksena oli haluttomuus tehdä muutoksia luokkahierarkiaan. Osa

välttämättömistä muutoksista jouduttiin tekemään talletustiedostoihin tekstieditorin avulla.

3.3.2 Olioiden väliset viittaukset

Rakenteellinen oliomalli on täynnä olioiden välisiä viittauksia. Nämä viittaukset voidaan tallettaa joko suorina osoittimina kohdeolion varaamaan muistitilaan tai vaihtoehtoisesti symbolisina niminä, joiden avulla haluttu olio voidaan hakea. Taulu­

kossa 2 on vertailtu symbolisen ja suoran viittaustavan vaikutuksia eri toimenpiteisiin.

Taulukko 2 Viittausten toteutustapojen vertailu

Toimenpide Symbolinen viittaus Suora muistiosoite {pointer)

Olion haku Hidas Nopea

Olion tuhoaminen Voidaan hoitaa viivästetysti, kunhan samalle nimelle ei luoda uutta oliota

Kaikki viittaukset tuhoutuneeseen olioon tulee päivittää, muutoin ohjelmisto kaatuu

Nimen vaihto Kaikki viittaukset tulee päivittää, jos nimi on osa symbolista nimeä

Ei mitään vaikutusta

Mallin

hajauttaminen

Malli voidaan jakaa eristettyihin kokonaisuuksiin, jotka voidaan myöhemmin yhdistää

Kaikkien olioiden tulee olla muistissa samaan aikaan. Jos osa olioista eristetään, ei yhdistämistä voida jälkikäteen suorittaa

Käytännössä symbolinen viittausmekanismi mahdollistaa mallin hajauttamisen, mutta on vastaavasti selvästi hitaampi. Stratexissa käytettiin yleensä symbolisia nimiä viittausten tallettamiseen ja mekanismin toteutuksessa oli muutamia ylimääräisiä ongelmia. Olion tuhoutumisesta ei mennyt välittömästi tietoa niihin olioihin, joista oli viittauksia tuhoutuneeseen olioon. Tuhoutumisen takia syntyneet virhetilanteet eivät näinollen tulleet välittömästi esille, vaan ne havaittiin mahdollisesti vasta seuraavalla kerralla viittausta käytettäessä. Malli saattoi siis olla viallisessa tilassa ilman, että järjestelmä antoi käyttäjälle mitään viestiä. Stratexin toteutuksessa symbolinen nimi koostui osaksi olion selväkielisestä nimestä. Käyttöliittymässä ei jälkikäteen ollut mahdollisuutta muuttaa olioiden selväkielisiä nimiä.

3.3.3 Sovelluskehitinominaisuuksien puuttuminen

Stratexin vahvimmat puolet johtuivat järjestelmän deklaratiivisesta tavasta kuvata mallia ja siihen liittyviä laskennallisia riippuvuuksia. Deklaratiivisten järjestelmien yleistymisen esteenä on usein kyvyttömyys ratkaista sinänsä yksinkertaisia, mutta deklaratiivisesti rumia toimintoja kuten tulostusta, arvojen kysymistä, tiedostojen käsittelyä, tapahtumien peräkkäistämistä ja käyttäjän ohjaamia tapahtumasarjoja.

Esimerkiksi käytännön toteutukset Prolog-ohjelmointikielestä sisältävät

deklaratiivisessa mielessä kauniin perusrakenteen lisäksi suuren joukon käyttöliittymän ja suorituksen ohjaukseen tarkoitettuja funktioita ja rakenteita.

Stratexiin ei haluttu ottaa mukaan proseduraalisia piirteitä. Pelättiin, ehkä aiheellisestikin, että muutamien proseduraalisten rakenteiden toteuttaminen olisi johtanut kierteeseen, jonka loputtua Stratexiin olisi toteutettu kaikki BASIC-tyyppisen ohjelmointikielen ominaisuudet ja funktiot. Koska proseduraalisia piirteitä ei ollut, voitiin Stratexin avulla rakentaa ainoastaan malleja, ei sovelluksia. Sovelluksen tunnuspiirteisiin voidaan katsoa kuuluvaksi sovelluksen käynnistyminen, sovelluksen eteneminen käyttäjän valintojen mukaisesti ja lopulta sovelluksen lopettaminen. Stratex- järjestelmässä mallin lataamisen jälkeen käyttäjän oli joka kerta manuaalisesti etsittävä

haluamansa raportit ja muutettavat lukuarvot.

Stratexilla rakennetusta mallista oli mahdotonta tehdä raportointisovellusta. Graafinen käyttöliittymä mahdollisti liikkumisen lähes mielivaltaisella tavalla mallin kehitysympäristössä, mutta raportointikäyttäjälle kehitysympäristön tapa esittää tietoa oli liian monimutkainen. Stratex-järjestelmästä puuttuivat myös asiakas/palvelin - ominaisuudet. Mallilla oli mahdollista olla kulloinkin vain yksi yhtäaikainen käyttäjä.

Usean yhtäaikaisen käyttäjän vaatimat lukitus- ja rinnakkaistamisominaisuudet koettiin teknisesti vaikeiksi lisätä TOP-ytimen avulla rakennettuun järjestelmään.

Raportointijärjestelmältä edellytetään vähintään kykyä esittää näkymiä, joilla voidaan rajata tarkasteltavia tietoja erilaisilla valinnoilla ja joiden välille voidaan luoda siirtymiä. Näkymien tiedot halutaan usein esittää graafisessa muodossa esimerkiksi pylväs-, viiva- tai piirakkadiagrammeina. Ilman kunnollisia liittymiä loppukäyttäjien jo tuntemiin sovelluksiin jouduttiin Stratexissa rakentamaan kaikki diagrammien esittämiseen tarvittavat ominaisuudet itse.

Sovelluskehitinominaisuuksien puuttumisen takia Stratexin markkinat jäivät suhteellisen pieniksi. Ainoastaan ne yritykset, joilla oli suuri tarve ja riittävät resurssit puhtaaseen tietokonepohjaiseen strategiseen suunnitteluun ottivat ohjelmiston käyttöönsä. Käytännössä yrityksissä tarvittiin yksi nimetty henkilö lähes kokopäivätoimisesti ylläpitämään mallia ja tulkitsemaan sen tuottamia lukuja.

3.3.4 Lisp-syntaksin mukainen laskentasääntökieli

Stratexin laskentasääntökielenä oli sisäänrakennetuilla funktioilla laajennettu Lisp [Tuom89]. Periaatteessa laskentasäännöissä saattoi esiintyä kaikkia Lisp-kielen rakenteita, globaaleja muuttujia ja funktiokutsuja. Tekniseltä toteutustavaltaan erinomaisella ratkaisulla oli kuitenkin kaksi erittäin huonoa puolta.

Kokeneet Lisp-asiantuntijat pystyivät kirjoittamaan liian monimutkaisia sääntöjä.

Koska täydellisten Lisp-ominaisuuksien avulla pystytään mallille tekemään lähes mitä tahansa asioita, ratkaistiin monet asiakkaiden haluamat toiveet jopa muutamien sivujen pituisilla, sivuvaikutuksiin perustuvilla, Lisp-lausekkeita sisältävillä laskentasäännöillä ja tulkinnoilla. Lausekkeiden ylläpito osoittautui erittäin hankalaksi. Erityisesti

asiakkaiden oli vaikea ymmärtää rakennettujen piirteiden toimintaa ja vaikutuksia, jolloin mallin oikeellisuudesta ei kokonaisuudessaan voitu varmistua.

Lisp-kieleen perehtymättömille vähänkin monimutkaisempien laskentasääntöjen kirjoittaminen saattoi osoittautua mahdottomaksi. Käyttäjälle tarkoitettu laskentasääntökieli sisälsi perusoperaattorit, vakiot, viittaukset mallin komponentteihin ja joukon valmiita funktioita. Koska käytössä olivat kaikki Lispin ominaisuudet, ei valmisfunktioiden tarvinnut kattaa kaikkia mallinnuksessa tarvittavia perustarpeita.

Esimerkiksi nykyiset taulukkolaskentaohjelmistot sisältävät useita satoja funktioita, Stratexissa valmisfunktioita oli vain parikymmentä. Suunnittelukäyttäjä joutui pyytämään Lisp-asiantuntijaa toteuttamaan kulloinkin tarvittavat ominaisuudet sovelluskohtaisina ratkaisuina.

3.3.5 Suurten asiakkaiden vaatimukset

Stratex oli asiakkaalle kallis ohjelmistoinvestointi, josta haluttiin saada irti mahdollisimman suuri hyöty. Kaupan yhteydessä käynnistettiin mittava konsultointiprojekti joka jatkui ylläpitoprojektina koko järjestelmän käyttöiän ajan.

Asiakasprojektit kuluttivat kuitenkin tehokkaasti myös käytettävissä olleet tuotekehitysresurssit. Stratexiin tehtiin kokopäiväisesti muutamien suurten asiakkaiden haluamia muutoksia ja uusia ominaisuuksia. Uusien piirteiden lisääminen tekee järjestelmästä monimutkaisemman, jolloin sen käyttöönottokynnys kasvaa. Uuden asiakasprojektin käynnistäminen olisi aina vaatinut mittavaa konsultointiprojektia, eikä järjestelmää päästy koskaan myymään ns. muoviin pakattuna hyllytavarana.