Asiakasprojektit

Kuvassa 30 on esitetty tyypillinen asiakasprojektin projektisuunnitelma. Projekti on jaettu erillisiin tehtäviin, joiden keskimääräiset kestot vuorokausina on esitetty tehtävien alapuolella. Suunnittelujärjestelmäprojekti alkaa aina myyntivaiheella, jonka aikana asiakas vakuuttuu toimittajan osaamisesta ja järjestelmän suorituskyvystä. Referenssit vastaavista projekteista ovat erittäin tärkeitä ja usein uudet asiakkaat haluavat tutustua toteutettuihin järjestelmiin niiden tuotantoympäristössään. Liitteessä E on esitetty asiakasprojekteista tehtyjä, markkinointimateriaalina käytettäviä sovelluskuvauksia.

Kuva 30 Asiakasprojektin kulku

Toteutusprojekti pyritään jakamaan kahteen kiinteähintaiseen osaan. Määrittelyvaiheen tavoitteena on kirjoittaa määrittely dokumentti, joka mahdollisimman tarkasti kuvaa haluttavan järjestelmän. Määrittelydokumenttiin kirjataan tyypillisesti järjestelmän sisältämien tietojen rakenteet, kaikkien järjestelmän näyttöjen kuvaukset yksittäisten tietojen ja painonappien tarkkuudella sekä tiedonsiirtoformaatit ulkoisista tietokannoista tai sisäänlukutiedostoista. Määrittelydokumentti on tehtävä niin huolellisesti, että sen perusteella voidaan tehdä kiinteähintainen tarjous koko järjestelmän toteutuksesta.

Sovelluksen rakentamisen tulisi olla suoraviivaista selkeän määrittelydokumentin pohjalta. MU ST-sovelluskehitin mahdollistaa sovelluksen rakenteiden interaktiivisen muuttamisen projektin aikana ja sen jälkeenkin, joten yleensä asiakkaalle annetaan mahdollisuus iteratiivisesti tarkentaa määrittelyvaiheessa pienemmälle huomiolle jääneitä osia. Jokainen muutos aiheuttaa kuitenkin sitä enemmän työtä, mitä myöhem­

min se tehdään, joten varsinainen määrittelyvaihe on tehtävä erittäin tarkasti.

Testaus ja asennusvaiheen aikana järjestelmän kaikki toiminnot pyritään käymään läpi.

Tärkeimpänä tavoitteena on löytää kaikki järjestelmässä olevat virheet. Testauksen aikana kannattaa myös tarkastella järjestelmän toimintaa mahdollisimman objektii­

visesti. Järjestelmää ei sellaisenaan kannata ottaa käyttöön, mikäli se ei täytä niitä tavoitteita jotka sille alunperin asetettiin, vaikka se olisikin tarkasti määrittely- dokumenttien mukainen. Monesti testausvaiheen aikana havaitaan pieniä laajennus- tarpeita, jotka toteutetaan erillisen kiinteähintaisen sopimuksen mukaisesti.

Kun asiakas on hyväksynyt järjestelmän, sen tuotantokäyttö voidaan aloittaa. Asiakas vastaa yleensä itse oman organisaationsa kouluttamisesta, jolloin toimittaja antaa muutaman päivän perus- ja ylläpitokoulutuksen järjestelmän pääkäyttäjille. Asiakkaan kanssa solmitaan lähes poikkeuksetta ylläpitosopimus, jonka tarkoituksena on pitää järjestelmä tuotantokäytössä mahdollisimman pitkään. Tietotekniikkainvestoinnista saatava kokonaishyöty on suoraan riippuvainen järjestelmän tehokkaasta käyttöiästä.

Kuvan 30 jatkotoimenpideprojekti on kuvaan mahtuakseen piirretty vain 33 vuorokauden mittaiseksi, keskimäärin onnistuneiden sovellusten käyttöikä on viidestä kymmeneen vuoteen.

MUST-sovelluskehittimen avulla on rakennettu useita asiakaskohtaisia sovelluksia.

Kokonaisia sovelluksia ovat rakentaneet ICL Data -ryhmän työntekijöistä Tarja Hynninen, Outi Impivaara, Teemu Lehto, Martti Paajanen, Sami Rosendahl ja Esa Pääkkönen. Aluksi tuotekehityksen ja asiakasprojekteja tekevien henkilöiden yhteistyö oli erittäin tiivistä. Yhteistyön tehostamiseksi liitettiin ICL Datan Johdon Järjestelmät - ryhmä osaksi ViSolutions Oy:tä syksyllä 1994. MUST-sovelluskehitin ei kuitenkaan vielä ole käytössä muissa asiakaskohtaisia sovelluksia rakentavissa yrityksissä.

Raportointijärjestelmät

Laman taittumisen jälkeen alettiin kesällä 1994 jälleen rakentaa raportointijärjestelmiä useille suomalaisille yrityksille ja valtion organisaatioille. Raportointijärjestelmät sisältävät tyypillisesti operatiivisia tietoja halutuille tarkkuustasoille summattuina ja näiden tietojen perusteella laskettuja tunnuslukuja. Raportointijärjestelmän operatiiviset tiedot päivitetään yleensä kuukausittain tai vuosineljänneksittäin, budjettitiedot joskus vain kerran vuodessa.

MUST-sovelluskehittimen avulla on rakennettu raportointisovelluksia, joihin on suoraan luettu sisään kaikki sovelluksessa näytettävät tiedot. Käsitemallin ytimenä on ollut joukko suoriteluokkia, joiden instansseihin suoritetason tiedot on talletettu.

Tyypillinen luokka olisi esimerkiksi organisaatioyksikön tuloslaskelma. Organisaation tasojen tuloslaskelman muodostavat organisaatiohierarkian, jonka mukaisesti ylemmän tason luvut saadaan laskettua alemmalla tasolla olevien yksikköjen summana.

Laskentasääntöjen avulla voidaan kätevästi huomioida myös tärkeät yksikön sisäiset tulot ja menot. Tunnusluvut saadaan laskettua kaikkiin yksiköihin samoilla laskentakaavoilla, jotka näinollen on kirjoitettava vain yhteen kertaan. Uusien tunnuslukujen lisääminen tai laskentakaavojen muuttaminen on erittäin helppoa.

Raportointisovelluksissa on pystytty hyvin hyödyntämään kaikkia kappaleissa 5.3.2 ja 5.3.3 esitettyjä ominaisuuksia. Osa ominaisuuksista onkin rakennettu nimenomaan raportointia varten. Erityisesti asiakkaat ovat arvostaneet tutun Excel-taulukkolaskimen käyttöä ja mahdollisuutta itse suorittaa näkymien lopullinen muotoilu.

Kokonaan MUST-järjestelmän avulla toteutettujen raportointisovellusten suurin ongelma on tietojen suuri määrä. 1980-luvun EIS-järjestelmät sisälsivät vain kymmeniä megatavuja tietoa, nykyiset DataWarehouse-järjestelmät puolestaan voivat sisältää useita gigatavuja tietoja. Normaalisti MUST-järjestelmässä kaikki tiedot ladattiin keskusmuistiin sovelluksen käynnistyksen yhteydessä. Koska tyypillisessä työasemassa oli noin 8 megatavua muistia, kehitettiin MUSTiin kaksi tietomassojen hallintaan liittyvää ominaisuutta.

Ensimmäinen oli numeeristen tietojen tallettaminen levyllä sijaitseviin erillistiedostoihin. Yhtä lukulistaa kohti varattiin tällöin vain 4 tavua keskusmuistia riippumatta listan pituudesta. Mikäli järjestelmässä haluttiin seurata kuukausittaisia toteuma-, budjetti- ja ennustetietoja viiden vuoden ajalta, varattiin levyltä tilaa 3(versiota) * 5(vuotta) * 12(kuukautta) * 8(tavua, double-tarkkuus) eli 1440 tavua.

Levyllä olevan tiedoston käyttö teki muutamien kymmenien megatavujen tietomäärien käsittelyn mahdolliseksi myös pienillä keskusmuisteilla varustetuissa koneissa.

Sovelluksen sisältämät laskennat luonnollisesti hidastuivat, sillä laskennan aikana levyhakuja ja kirjoituksia tuli paljon. Raportointisovelluksissa suurin osa tiedoista lasketaan valmiiksi kuukausittaisten sisäänlukujen yhteydessä.

Toinen tietomassojen hallintaan liittyvä merkittävä parannus oli palvelinominaisuuksien rakentaminen. Palvelin mahdollisti käyttöliittymän ajamisen eri tietokoneessa kuin varsinaisen sovelluksen. Yhteen palvelimeen voitiin myös liittyä usealta eri mikrotietokoneelta, jolloin jokaiselle käyttäjälle luotiin oma näkymäavaruus. Tällöin suuri sovellus voitiin ladata tehokkaaseen palvelinkoneeseen, jolloin työasemilla tarvittiin ainoastaan Excel ja pieni yhteysohjelmisto.

Strategisen suunnittelun tukijärjestelmät

Strateginen suunnittelu on yritysten johdossa tapahtuvaa pitkän tähtäimen suunnittelua, ks. kappale 2.3.5. Tehtävillä päätöksillä on suoria ja epäsuoria vaikutuksia useiden vuosien ajalle. Strategisen suunnittelun tukeminen on aina kuulunut tämän projektin tärkeinpiin tavoitteisiin.

Strategisen suunnittelun järjestelmille on ominaista käsitemallin monimutkaisuus.

Sovellukset sisältävät numeerisen tiedon lisäksi paljon rakenteellista tietoa. Strategiset päätöksetkin ovat usein luonteeltaan rakenteellisia, esimerkiksi uuden kaivoksen rakentaminen, konsernin osan yksityistäminen itsenäiseksi yritykseksi, uusien tuotteiden, tuotantolinjojen tai jakelukanavien perustaminen, vaihtoehtoisten raaka- aineiden käyttäminen tai investointien toteuttaminen. Tyypillisesti tehdyillä päätöksillä on laskennallisia vaikutuksia moniin sovelluksen osiin.

MUST-järjestelmän luokkahierarkian avulla voidaan tehokkaasti kuvata strategisen suunnittelujärjestelmän käsitemalli. Strateginen suunnittelumalli on aina abstraktio

reaalimaailmassa esiintyvästä todellisesta tilanteesta. Luokkahierarkia sisältää usein abstrakteja yläluokkia, joiden tarkoituksena on koota yhteen erilaisten asioiden yhteisiä ominaisuuksia. Toisaalta useiden lehtiluokkien avulla voidaan hallita epähomogeenisessa ympäristössä aina esiintyviä poikkeustapauksia. Tarkasteltavan yrityksen kuvaaminen käsitemallin sisältämien luokkien instansseina selkeyttää suunnittelijan yleistä kuvaa omasta yrityksestään. Kaikki olennaiset riippuvuudet eri yksikköjen välillä tulisi havaita ja kirjoittaa niitä vastaavat laskentasäännöt.

Strategisen suunnittelun seurantajakso on yleensä yksi vuosi. Kerran vuodessa suunnittelumalli päivitetään toteutuneilla tiedoilla ja organisaation eri osista saatavilla ennustetiedoilla. Sovelluksen varsinainen käyttö on vilkkainta juuri päivitysten yhteydessä. Ajan tasalla olevaan mallin tehdään mahdollisia strategisia päätöksiä vastaavia muutoksia sekä tarkastellaan erilaisia tulevaisuuden skenaarioita. MUST- järjestelmän interaktiivinen käyttöliittymä ja tehokas laskentamekanismi mahdollistavat

monipuoliset mitä-jos -tarkastelut kaikille mallin tiedoille ja rakenteille.

Sovelluskehitinominaisuuksien avulla strategisen suunnittelun sovellusten käyttö on saatu helpoksi järjestelmää harvemmin käyttäville käyttäjille. Excel-taulukkolaskin on ollut onnistunut valinta grafiikoiden piirtämiseen, järjestelmän antamat tulokset on saatu suoraan esityskelpoisina kuvina. Samalla on voitu tarkastella muutosten vaikutuksia todellisiin lopputuloksiin. Perustietojen ja operatiivisten lukujen syöttäminen luotuihin instansseihin voidaan monesti tehdä sisäänlukurutiinien avulla tietokannoista tai tekstitiedostoista.

Suurissa konserneissa on usein havaittu tarpeelliseksi strategisen suunnittelun hajauttaminen alemmille organisaatiotasoille. Esimerkiksi ICL Datan strategisessa suunnittelussa käytetään divisioonatasolla omia suunnittelumalleja. Divisioonien malleissa voidaan suunnittelua tehdä haluttaessa hyvinkin yksityiskohtaisesti.

Osamallien luvut siirretään tiedostoina konsernimalliin, jossa voidaan tarkastella suurienkin rakenteellisten muutosten vaikutuksia.

SQL-sovelluskehitin

Nykyisin rakennettavien asiakas/palvelin -järjestelmien palvelimena on yleensä relaatiotietokanta. Järjestelmät voivat sisältää erittäin paljon tietoa ja ne ovat hyvin vakaita. Teoreettisestikin luotettavaksi todettu trasaktiomekanismi mahdollistaa järjestelmän selviytymisen jopa laitteistovioista, sähkökatkon jälkeen voidaan palata takaisin viimeisimpään hyväksyttyyn tilanteeseen. W indo ws-käyttöj ärj estelmässä relaatiotietokantojen käyttö helpottui huomattavasti ODBC-standardin valmistumisen jälkeen. Nykyisin kaikkia merkittäviä relaatiotietokantoja voidaan käyttää saman rajapinnan avulla.

Palvelimen kanssa kommunikoivan asiakassovelluksen rakentamiselle on monta vaihtoehtoa. Perinteisesti tietokannan rakentaja tarjosi omat kehitysvälineensä, joiden avulla asiakaskohtaiset sovellukset oli rakennettava. Nykyisin asiakasohjelmien rakentamiseen tarkoitettuja kaupallisia sovelluskehitysvälineitä on kymmeniä, jopa

satoja. MUST-sovelluskehitin on yksi näistä välineistä ja sillä on rakennettu kolme suurta asiakaskohtaista raportointisovellusta.

MUST-sovelluksesta voidaan tehdä merkkipohjaisia relaatiotietokantakutsuja standardin ODBC-rajapinnan avulla. Kutsuja voidaan tehdä sekä laskentasääntökielen avulla, että suoraan näkymiin liitettyjen solujen kautta. Molemmissa tapauksissa MUST-jäijes- telmän laskentasääntökieltä käytetään tarvittavien SQL-lauseiden muodostamiseen.

Laskentasääntöjen avulla lauseet muodostetaan käyttäjän kulloistenkin valintojen mukaisesti. Kun käyttäjä vaihtaa valintojaan näkymiin liitettyjen painonappien avulla, invalidoituvat SQL-lauseet automaattisesti. Päivitysmekanismi takaa, että parhaillaan auki olevien näkymien lauseet suoritetaan automaattisesti, joten sovelluksen rakentajan ei tarvitse erikseen kutsua palvelinta. MUST-sovellukseen voidaan myös hallitusti puskuroida istunnon aikana tehdyt kutsut perustietotauluihin siten, että yhdistelyjen (join) määrä saadaan minimoitua.

SQL-sovelluksissa käytetään muutoin hyväksi samoja piirteitä kuin raportointi- sovelluksissakin. Sovellukset on tarkoitettu lähinnä tietojen tarkastelua varten, eikä niissä yleensä voida tehdä mitä-jos -tyyppisiä tarkasteluja.

6.3.2 Asiantuntijajärjestelmäkehitin ja tekoälykieli

Seppo Linnainmaan mukaan asiantuntijajärjestelmä (expert system) on tietämys­

järjestelmä (iknowledge-based system), joka jäljittelee ihmisasiantuntijan päättelyä ja kommunikoi käyttäjänsä kanssa tällaisen asiantuntijan tavoin [HyKaSy93]. Yleisen määritelmän antaminen on vaikeaa, sillä ansiantuntij aj ärjestelmiksi on kutsuttu niin yksinkertaisia tietämyksen jäsentämisohjelmia kuin monimutkaisia päättely­

järjestelmiäkin. Teoreettisen määritelmän mukaan asiantuntijajärjestelmällä on seuraavat ominaisuudet [Stee87]:

• Se on tietokoneohjelma, joka on suunniteltu auttamaan ihmistä jonkun todellisen, rajoitetun ja vaikean ongelman ratkaisussa.

• Sen päättely j älj ittelee asiantuntij an päättelyä.

• Sillä on koko ajan sisäinen kuva tilastaan ja toiminnastaan, mikä mahdollistaa tulosten selittämisen ja perustelemisen.

• Sen käyttöliittymä perustuu luonnolliseen kieleen ja/tai graafiseen vuoro­

vaikutukseen, toisin sanoen järjestelmä on suoraan käyttäjän käytettävissä.

Nykyiset MU ST-sovellukset täyttävät kaikki edellä esitetyt vaatimukset. Sovelluksen päättely perustuu asiantuntijan antamiin laskentasääntöihin. Sovelluksen sisäinen kuva muodostuu sen sisältämien instanssien ja niiden attribuuttien arvoista kunakin ajanhetkenä. Laskenta voidaan asettaa tuottamaan viestejä, joiden avulla päättelyn (laskennan) etenemistä voidaan seurata halutulla tarkkuudella. Käyttöliittymä perustuu kokonaisuudessaan graafiseen vuorovaikutukseen.

Yksinkertaiset asiantuntijajärjestelmät tehdään nykyään valtaosin erityisillä asiantuntij ajärj estelmäkehittimillä (expert system shell), koska näiden käyttö on varsin vaivatonta verrattuna varsinaisten ohjelmointikielten käyttöön. Isoissa järjestelmissä

ongelmia aiheuttavat kokonaisuuden hallinta ja toiminnan hitaus. Halpojen kehittimien ongelmia ovat lisäksi vähäiset mahdollisuudet vaikuttaa käyttöliittymän toteutukseen ja liittymiin muihin ohjelmistoihin. Nokia Tutkimuskeskuksessa rakennettiin XiPlus- asiantuntij aj ärj estelmäkehittimen tietämyskantoja C-kieliseksi ohjelmakoodiksi kääntävä sääntökääntäjä [Noki90], Kääntäjän käyttö poisti hitauteen liittyvät ongelmat ja mahdollisti integroinnin C-kielisiin käyttöliittymäkirjasioihin. Käännetty sovellus ei kuitenkaan enää sisältänyt selitystoimintoja eikä siinä ollut peruutustoimintoa annettujen syöttötietojen muuttamiseen.

Vaativampien asiantuntijajäijestelmien ohjelmoinnin perustana ovat usein erityiset tekoälykielet, joilla harjaantuneet asiantuntijajärjestelmien kehittäjät voivat korvata sinänsä helppokäyttöiset, mutta usein käyttömahdollisuuksiensa puolesta rajoittuneet kehittimet. Tekoälykielet tarjoavat mahdollisuudet tehokkaaseen symbolien käsittelyyn ja suorituksen aikana voimakkaasti muuntuviin tietorakenteisiin, esimerkiksi itseään muuttaviin ohjelmiin. Yleisimpiä tekoälykieliä ovat luvussa 4 mainittujen Lisp- ja SmallTalk-kielien lisäksi logiikkaohjelmointiin perustuva Prolog-kieli. Nykyisin myös C++-kielen käyttö on lisääntynyt, vaikka asiantuntijärjestelmien rakentaminen sillä on työläämpää kuin edellä mainituilla kielillä. [Seppo Linnainmaa (HyKaSy93)]

MU ST-so velluskehitintä voidaan käyttää sekä asiantuntij aj ärj estelmäkehittimenä että tekoälykielenä. Sen avulla voidaan nopeasti rakentaa tietämyksen rakenteelta monimut­

kaisiakin sovelluksia. Järjestelmä hoitaa itse päättelyn ja laskennan suorittamisen syötettyjen laskentasääntöjen perusteella. Sovellukseen voidaan rakentaa interaktiivinen graafinen käyttöliittymä, jonka ulkoasun muotoilussa voidaan käyttää kyväksi Excel- taulukkolaskinta. Toisaalta MUST-j ärj estelmän sisältämä laskentasääntökielimekanismi valmiine funktioineen mahdollistaa täysipainoisen ohjelmoinnin. Käyttäjä voi halutessaan kirjoittaa myös proseduraalista koodia, joka voi esimerkiksi muuttaa sovelluksen sisäistä rakennetta tai luoda sovellukseen kokonaan uusia käsitteitä (luokkia). Käyttäjä voi myös ohjata päättelyä laskentasääntökohtaisesti optimoidakseen lopullisen sovelluksen suorituskykyä tai luodakseen erilaisiin tapahtumiin reagoivia hälyttimiä {trigger).

Mikäli MUST-järjestelmää haluttaisiin markkinoida erityisesti asiantuntijajärjestelmien tekemiseen, kannattaisi siihen tehdä useita pieniä parannuksia. Päättelypuita tulisi voida tarkastella graafisina verkkoina, joissa edettäisiin hiiriohjatusti käyttäjän valintojen mukaisesti. Yksittäisen laskentasäännön arvon laskenta tulisi myös havainnollistaa vaiheittain, sillä useita z/-lauseita sisältävän säännön suoritettujen haarojen päätteleminen ei aina ole sovelluksen rakentajalle helppoa. Interaktiivisen sääntökantasovelluksen rakentamisessa voitaisiin myös hyödyntää uutta tietoalkiotyyppiä. Alkion arvon tulisi sisältää vaihtoehto ‘ei tiedossa’ {unknown). Mikäli tällaisen attribuutin arvoa ehdottomasti tarvittaisiin eikä sitä saataisi mistään pääteltyä, kysyisi järjestelmä arvon automaattisesti käyttäjältä.

6.3.3 Päättely ja laskenta temporaalilogiikassa

Temporaalilogiikassa muuttujilla voi olla erilaisia arvoja eri ajanhetkinä. MUST- järjestelmällä voidaan hallita diskreetteihin ajanhetkiin jaettuja tietoja pääsääntöisesti

seuraavilla kahdella tavalla.

Aikasarjoihin perustuva ajan käsite

MUST-järjestelmässä aikaan sidotut muuttujien arvot voidaan tallettaa suoraan yhden aikasarjatyyppisen muuttujan arvolistan alkioiksi. Listalle voidaan määritellä alkuhetki, alkioiden ajallinen välimatka ja alkioiden lukumäärä. Lukulistassa olevaa yhtä lukua kutsutaan kyseisen kauden luvuksi. Esimerkiksi alkuhetki voi olla vuosi 1993, alkioiden välimatka 1 vuosi ja alkioiden lukumäärä 5 kappaletta. Vuoden 1993 lukuarvoa vastaa listan ensimmäinen luku, jota kutsutaan ensimmäisen kauden luvuksi.

Peräkkäisten kausien lukuarvot on heippo tallettaa aikasarjan peräkkäisiin alkioihin.

Automaattiset sisäänlukurutiinit voidaan kirjoittaa siten, että lukuarvoa talletettaessa annetaan sisäänlukukauden ajankohta selväkielisenä päivämääränä. Aikasarjassa olevia lukuja on myös helppo siirtää graafiseen käyttöliittymään lukusarjoina.

Lukusarjalle kirjoitettua laskentasääntöä sovelletaan kaikille lukusarjan luvuille. Eri kausien lukuarvot voidaan kuitenkin huomioida säännön lausekkeessa, jolloin historiatiedoille, nykypäivälle ja ennustuksille voidaan kirjoittaa erilaiset säännöt.

Oheinen sääntö valitsee laskentasääntökielen //"-funktion avulla eri kausille oikean säännön:

if([1 1 0 0 0], historia, if ([00100], nykypäivä, tulevaisuus))

Säännössä voidaan viitata edellisiin tai'seuraaviin kausiin laskentasääntökielen prev- ja

«ext-funktioilla. Sääntö X = prev( X) + Г sijoittaa tietoalkion x arvoksi lukusarjan 1,2,3... Temporaalilogiikan operaattori PX, X oli tosi jonain menneisyyden ajanhetkenä, voidaan laskea säännön 'PX = prev(PX) OR prev(X)' avulla. Yrityksen vapaa oma pääoma voidaan laskea yksinkertaistetulla säännöllä 'VapaaOmaPääoma = prev(VapaaOmaPääoma) + Voitto - Osingot'. Aikasaijojen avulla peräkkäisten kausien

lukuja on vaivatonta käsitellä, mutta ajassa ei saa tapahtua haarautumia.

Kehyksiin perustuva ajan käsite

Suunnitteluun usein liittyvissä skenaarioissa ajan käsite on keskeisessä asemassa.

Monimutkaisempia ajallisia kokonaisuuksia voidaan käsitellä aikaan sidottujen kehyksien avulla. Kehys voi vastata käyttötavasta riippuen joko yksittäistä ajanhetkeä tai tiettyä aikaintervallia. Kehyksien välille muodostetaan aikarelaatio, joka määrittelee kehyksien ajallisen järjestyksen.

MUST-järjestelmässä aikarelaatio voidaan muodostaa kaksisuuntaisen relaatioparin avulla. Kehystä ajallisesti seuraavat muut kehykset voidaan kiinnittää relaatioon tulevaisuus ja kehystä ajallisesti ennen olevat relaatioon menneisyys. Lineaarista aikaa kuvattaessa molempien relaatioiden kardinaliteetti on yksi. Edellisessä kappaleessa

kuvatut esimerkit voidaan nyt kirjoittaa 'PX = get(menneisyys.PX) OR get(menneisyys.X)' ja 'VapaaOmaPääoma = get(menneisyys.VapaaOmaPääoma) +

Voitto - Osingot'.

Vaihtoehtoisia skenaarioita mietittäessä on usein hyödyllistä sallia useiden vaihtoehtoisten tulevaisuuksien olemassaolo. Tämä voidaan sallia asettamalla tulevaisuus relaation kardinaliteetiksi monta. Oheinen kuva esittää tilannetta, jossa nykyhetkeä voi seurata kaksi toisensa poissulkevaa tulevaisuudenhetkeä, lama ja nousukausi.

ama'

Kasvuprosentti = 5%

Todennäköisyys = 0.2

Nousukausi'

Kasvuprosentti = 20%

Todennäköisyys = O.a,

Kuva 31 Vaihtoehtoisten tulevaisuuksien esittäminen Kuvassa esiintyvä nykyhetken arvo voitaisiin laskea esimerkiksi seuraavasti:

Myynti = sum(tulevaisuus.Arvo * tulevaisuus.Todennäköisyys)

Menneisyyden haarautuminen voidaan vastaavasti sallia asettamalla menneisyys- relaation kardinaliteetiksi monta. Vaihtoehtoisten menneisyyksien perusteella tehtävää laskentaa ei kuitenkaan yleensä tarvita yrityssuunnittelussa. Järjestelmän kannalta ajan haarautuminen molempiin suuntiin ei ole ongelma, sovellusalueiden löytäminen ja mielekkäiden laskentasääntöjen keksiminen voi sitävastoin osoittautua hankalaksi.

6.3.4 Algoritmien toiminnan havainnollistaminen

Osoituksena MU ST-j ärj estelmän oliomallinnusominaisuuksien ilmaisuvoimasta esitetään tässä kappaleessa tapa havainnollista rekursioon perustuvan algoritmin toimintaa dynaamisesti muuttuvan oliomallin avulla. Rekursiivisesti etenevässä algorit­

missa kutsutaan ensimmäiseksi ylimmällä tasolla olevaa käynnistysfunktiota. Funktio pilkkoo ongelman osiin ja antaa osat muiden funktioiden ratkaistaviksi. Lopulta ylemmällä tasolla kootaan vastaus alemman tason funktioiden paluuarvoista.

Rekursiivisen algoritmin etenemistä voidaan oliomallin avulla kuvata siten, että jokaista funktion suoritusympäristöä varten luodaan yksi instanssi. Funktion pinosta varaamia muuttujia varten määritellään funktion suoritusympäristöä esittävään luokkaan vastaavat attribuutit. Varsinaiset funktiokutsut esitetään relaatioina, joissa kutsuvan funktion suoritusympäristön relaatioihin luodaan kutsuttavia funktioita vastaavat suoritus­

ympäristöt.

Otetaan esimerkiksi tuttu QuickSort-lajittelualgoritmi, joka lajittelee saamansa listan kasvavaan järjestykseen. Alla on esitetty algoritmim proseduraalinen kuvaus C- ohjelmointikieltä muistuttavalla pseudokielellä:

function quicksort (1 : objectList) : return objectList { if (1.size() <= 1) return 1;

object pivot = l.atomAt(O);

objectList smallers = 1.objectsSmallerThan(pivot);

objectList biggers = 1.obj ectsBiggerOrEqualThan(pivot) - pivot ; return quicksort(smallers) + pivot + quicksort(biggers);

}

Algoritmi valitsee ensin listasta ns. pivot-alkion. Alkion valinta voidaan suorittaa monella tavalla, yksinkertaisin tapa on valita listan ensimmäinen alkio. Tämän jälkeen lajiteltava lista jaetaan kahteen osaan siten, että toiseen tulevat pivot-alkiota pienemmät ja toiseen suuremmat alkiot. Pivot-alkion kanssa samansuuruiset alkiot tulee ottaa mukaan toiseen listoista ja pivot-alkiota itseään ei oteta mukaan kumpaankaan listaan.

Jakamisen jälkeen algoritmi kutsuu rekursiivisesti itseään lajittelemaan erikseen pienet ja suuret alkiot. Lopullinen vastaus saadaan muodostamalla lista lajitelluista alkioista ja

valitusta pivot-alkiosta.

Rekursiivinen algoritmi voidaan havainnollistaa MUST-j ärj estelmässä seuraavien sääntöjen mukaisesti:

1. Jokaista suorituskertaa (kutsua) kohti luodaan oma instanssi.

2. Jokainen kutsun pinosta varaama muuttuja esitetään luokkaan luotuna attribuuttina.

3. Kutsussa siirtyvät parametrit lasketaan valmiiksi kutsujan pinosta varaamiin muuttujiin.

4. Rekursiivinen kutsu esitetään kaksisuuntaisen relaatioparin avulla siten, että kutsuja luo kutsuttavan pinoa vastaavan instanssin, jonka relaation vastinpariin päivittyy viittaus kutsujaan.

Edellisten sääntöjen mukaisesti QuickSort-algoritmi voidaan esittää luomalla taulukon 13 mukaiset relaatiot laskentasääntöineen. Koska rekursiivinen kutsu täytyy esittää relaatioparin avulla, joudutaan luokasta luomaan kaksi alaluokkaa. Varsinainen ylimmän tason funktionkutsu mallitetaan siten, että relaation ListToSort arvoksi asetetaan alkuperäinen lajiteltava lista. Tämä lista voidaan muodostaa esimerkiksi kaikista mallissa olevista yritysluokan instansseista säännöllä instancesOfClass(&C&Company). Rekursiivista kutsua varten luotuun alaluokkaan on luotava vastinparit relaatioille BigSorter ja SmallSorter. Lajiteltavat alkiot haetaan nyt kutsujan pinoa vastaavista muuttujista säännöllä BigSorter. BigSOs + SmallSorter. Smal ISOs.

Taulukko 13 QuickSort-algoritmia vastaavan luokan relaatiomäärittelyt Relaatio Kard. Kohde Laskentasääntö

ListToSort 1-N SO

SortedList 1-N SO SmallSorter. SortedList + CurrentSO + BigSorter.SortedList;

CurrentSO 1 SO first ( ListToSort ) ;

BigSOs 0-N SO choosemany (ListToSort.SortValue >= get (

CurrentSO.SortValue ) , ListToSort ) - CurrentSO;

SmallSOs 0-N SO choosemany ( ListToSort.SortValue < get ( CurrentSO.SortValue ) , ListToSort );

BigSorter 0-1 Sorter if ( count ( BigSOs ) > 0, setcardinality ( 1,

&C&"RecursiveQuickSort", nameOfThis ( 1 ) + "B" ) , 0 ) SmallSorter 0-1 Sorter ^if ( count ( SmallSOs ) > 0, set cardinality ( 1,

&C&"RecursiveQuickSort", nameOfThis ( 1 ) + "S" ) , 0 ) Algoritmi on nyt esitetty deklaratiivisesti ja MUST-järjestelmä takaa muodostuvan oliomallin jäijestäytymisen laskentasääntöjen mukaisesti siten, että alkuperäinen lista saadaan lajiteltua. Uusia instansseja luodaan säännön set cardinality avulla tarvittaessa.

Lajiteltavien olioiden muuttuessa rekursiopuu muuttaa vastaavasti muotoaan.

Rekursiivista kutsua varten luotuun alaluokkaan on hyvä lisätä sääntö, joka tuhoaa instanssin mikäli se on irroitettu puusta. Tällainen sääntö on esimerkiksi tietoalkiolle GarbageCollector kirjoitettu sääntö 'if(count(ListToSort)=0,deleteThisInstanceQ,l)'.

Kuva 32 Quicksort-algoritmin suorituksia vastaavat näkymät

Kuvassa 32 on esitetty kaksi näkymää malliin, joka havainnollistaa QuickSort- algoritmin suoritusta. Ylemmässä ikkunassa on rekursiivisen kutsupuu ja alempi sisältää taulukkomuotoisen esityksen lajiteltavista ja lajitelluista alkiosta (Compl...Comp7).

Vasemmanpuoleinen suoritus on tasapainoinen. Ensimmäinen pivot-alkio on arvoltaan 70 ja se jakaa muut alkiot täsmälleen kahteen yhtäsuureen listaan. Samoin käy myös molemmissa alemman tason jaoissa, sillä pivot-alkioiksi tulevat ensimmäiset alkiota 70 suurempi ja pienempi luku, tässä 90 ja 20. Oikeanpuoleinen suoritus on saatu aikaan muuttamalla alkion Comp5 arvo lukuarvosta 90 arvoon 35. Instanssinäkymä päivittyy välittömästi muutoksen jälkeen rakenteeseen liittyvien laskentasääntöjen lauetessa havainnollistaen uuden kutsurakenteen. Ensimmäinen pivot-alkio 70 ei enää jaa listaa kahteen yhtä suureen osaan. Lukuarvoa 70 suurempia alkioita on enää kaksi, joten vasemmanpuoleisessa verkossa ollut instanssi TestBS tuhoutuu. Toisaalta lukuarvoa 70 pienempiä alkioita on nyt yksi enemmän, joten niiden lajittelemiseen tarvitaan uusi instanssi TestSBS.

6.4 Toteutuksen oikeellisuuden todistaminen

Tietokoneohjelman oikeellisuus voidaan periaatteessa todistaa alkaen yksinkertaisista operaatioista ja muodostamalla näistä kaikki esiintyvät kombinaatiot [GrieSl].

Käytännössä käyttäjän ohjaamien ohjelmien oikeellisuuden todistaminen kaikissa mahdollisissa tilanteissa on mahdotonta. MUST-j ärj estelmän ytimen, MOS-kiij aston, oikeellisuus voidaan kuitenkin riittävällä tasolla todistaa käyttämällä hyväksi mallin tilaa kuvaavia aksioomia, jotka ovat voimassa jokaisen perusoperaation suorituksen jälkeen. MOS-kirjastossa on noin 20 luokkaa, joista jokaisessa on keskimäärin 25 metodia. Näistä viidestäsadasta metodista kuitenkin vain noin sata voi muuttaa mallin

Käytännössä käyttäjän ohjaamien ohjelmien oikeellisuuden todistaminen kaikissa mahdollisissa tilanteissa on mahdotonta. MUST-j ärj estelmän ytimen, MOS-kiij aston, oikeellisuus voidaan kuitenkin riittävällä tasolla todistaa käyttämällä hyväksi mallin tilaa kuvaavia aksioomia, jotka ovat voimassa jokaisen perusoperaation suorituksen jälkeen. MOS-kirjastossa on noin 20 luokkaa, joista jokaisessa on keskimäärin 25 metodia. Näistä viidestäsadasta metodista kuitenkin vain noin sata voi muuttaa mallin

In document Design and implementation of a functional object-oriented application development system (sivua 106-0)