4 VAIHTOEHTOISET LÄHESTYMISTAVAT
4.4 Toteutusvaihtoehdot C++-kielellä
4.4.1 Oliomallinnusominaisuudet
Tässä työssä haluttiin rakentaa oliopohjainen mallinnusympäristö, jossa loppukäyttäjä voi luoda uusia luokkia ja näiden luokkien instansseja. Koska C++-luokkia ei suorituksen aikana ole olemassa, jouduttiin ajonaikainen luokka- ja instanssij ärj estelmä toteuttamaan ilman C++:n staattisten periytymisominaisuuksien apua. CLOS- toteutuksessa voitiin käyttää suoraan hyväksi järjestelmän tarjoamia tapoja uusien luokkien hallintaan, jolloin loppukäyttäjä loi itseasiassa CLOS-jäijestelmän luokkia.
C++-toteutuksessa loppukäyttäjä ei voi luoda C++-luokkia.
Assosiaatioille on olemassa kaksi vaihtoehtoista toteutustapaa [Rumb91]:
1. Luodaan assosiaation molempiin päihin attribuutit, joiden arvona on assosiaatioon liittyneet kohdeluokan instanssit. Tämä tapa mahdollistaa tehokkaimman mahdolli
simman käsittelyn, mutta vaatii vastakkaisten päiden päivittämistä jokaisen muutoksen ykteydessä. Mikäli käsittelyä on useammin kuin muutoksia, on tämä tapa hyvä vaihtoehto.
2. Assosiaatio voidaan toteuttaa itsenäisenä oliona, joka ei suoranaisesti liity mihin
kään luokkaan. Assosiaatio-olio olisi joukko assosiaatiossa olevia instanssipareja talletettuna yhteen muuttuvamittaiseen hakemisto-olioon (dictionary), kuva 9.
Käsittely olisi hitaampaa kuin attribuutteihin perustuvassa ratkaisussa, sillä yhteen instanssiin liittyvät kohdeinstanssit tulisi hakea mahdollisesti pitkästäkin taulusta.
Harvojen matriisien esittämiseen tietorakenne sopii mainiosti, sillä tilaa varataan ainoastaan niille instansseille, joiden välillä assosiaatio todella on olemassa.
<^PersonT^>.
(^PersonjT^.
C^PersonT>.
Works-for
j^CompañyT)
<^Company2^>
Kuva 9 Assosiaation toteuttaminen j oukkona instanssiparej a
Tässä työssä tarvittavat assosiaatiot toteutettiin kaksisuuntaisten attribuuttien, relaa
tioiden avulla. Laskennallisten ominaisuuksien takia assosiaatioita pitkin edetään usein, joten käsittelyn tulee olla mahdollisimman tehokasta. Laskentasääntömekanismiin liittyvän invalidointimekanismin takia yksittäisessä instanssissa olevan assosiaation arvo on voitava invalidoida. Mikäli kohdeluokkien instansseihin ei tallettuisi mitään tietoa assosiaatiosta (tapa 2), ei invalidointiakaan voitaisi tehokkaasti toteutettua.
4.4.2 Evaluointiominaisuudet
C++ ei sisällä suoraan tapaa laskea ohjelman suorituksen aikana tekstimuodossa esitetylle lausekkeelle arvoa. Sekä jäsentämistä että evaluoimista varten on joko kirjoitettava omat rutiinit tai vaihtoehtoisesti käytettävä joitain valmiita kirjastoja. Tässä työssä käytettiin alkuvaiheessa valmista kirjallisuudesta löytyvää ratkaisua, mutta rakennettiin myöhemmin uusi tehokkaampi ja paremmin oliomalliin sopiva ratkaisu.
4.4.3 Tyyppiorientoituneisuus
C++-toteutuksessa ei voitu käyttää aikaisemman toteutuksen mukaisia tyyppi- orientoituneita piirteitä. Koska nämä piirteet eivät olleet kuitenkaan osoittautuneet kovinkaan havainnollisiksi tai helppokäyttöisiksi tavoiksi ratkoa sovelluksien sisältämiä ongelmia, päätettiin tyyppiorientoituneisuus toteuttaa ainoastaan tietoalkioiden tyypi
tyksen osalta. Tietoalkioiden erilaisten tyyppien takia jouduttiin mm. käyttöliittymän takia toteuttamaan yleiskäyttöiset rajapinnat erilaisten sisäisten tyyppien käsittelyyn.
4.4.4 Tietokantaratkaisu
Järjestelmän keskeinen komponentti on tietokanta, johon kaikki sovelluksen tiedot tallettuvat. Tietokantaratkaisuun vaikuttavat erityisesti seuraavat kriteerit:
• Ohjelmiston perusarkkitehtuuri - Rakennettu järjestelmä on perusarkkitehtuuriltaan oliopohjainen. Kaikki rakenteellinen tieto on esitetty luokkina, olioina, tietoalkioina ja olioiden välisinä viittauksina. Tietoalkiot sisältävät puhdasta datatietoa, joka voi
tyypiltään olla merkkijono, luku tai lukulista.
• Tiedon määrä - Varsinaisen hyötytiedon määrä asettaa minimivaatimukset tallennus
kapasiteetille. Mikäli suunnittelujärjestelmässä halutaan tarkastella operatiivisia, helposti kerättäviä tietoja, kertyy tietoja helposti useita satoja megatavuja. Toisaalta strategiseen suunnitteluun liittyviin järjestelmiin kerätään usein rakenteellisesti monimutkaisempaa ja luonteeltaan abstraktimpaa tietoa, jolloin tiedon määrä voi olla vain muutamia megatavuja.
e Haluttu käyttäytyminen virhetilanteissa - Virhetilanteet voidaan pääsääntöisesti jakaa käyttäjän erehdyksiin ja ohjelmiston tai laitteiston vikoihin. Yleisen tavan mukaisesti käyttäjälle tulisi antaa mahdollisuus peruuttaa ainakin viimeksi tehty operaatio. Käyttäjä on voinut vahingossa valita aivan väärän operaation tai hän voi haluta peruuttaa operaation nähtyään sen vaikutukset. Ohjelmistossa tai laitteistossa esiintynyt vika ei saisi tuhota järjestelmän tietoja. Yksinkertaisissa ongelmatilanteissa pitäisi järjestelmän itse jatkaa peruuta-toiminnolla. Mikäli ohjelman suoritusta ei ole mahdollista jatkaa, pitäisi sovellus pystyä käynnistämään viimeksi talletetusta tai hyväksytystä tilanteesta.
• Halutut vasteajat - Aika on rahaa, ja tietokoneohjelmien tulisi yleisesti olla ihmisiä nopeampia. Interaktiivisessa käytössä yleisimpien operaatioiden tulisi kestää alle viisi sekunttia. Pitkät lataus-ja talletusajat vaikuttavat suoraan työn tehokkuuteen.
• Järjestelmän sisäiseen rakenteeseen tulevat muutokset - Sovelluskehittimen avulla rakennetaan sovelluksia. Sovelluksiin tehtävät muutokset, esimerkiksi uusien luokkien luominen, eivät mitenkään vaikuta sovelluskehittimen lataus- ja talletus- formaatteihin. Mikäli itse sovelluskehittimeen tulee muutoksia, järjestelmää laajen
netaan tai sisäisiä tietorakenteita optimoidaan, voi lataus- ja talletusformaatteihin tulla muutoksia. Yhteensopivuus vanhojen versioiden kanssa on erittäin tärkeää.
Vähimmäisvaatimuksena on sovelluskehittimen pystyttävä lataamaan kaikki kehittimen aikaisemmilla versioilla talletetut sovellukset.
e Lisenssitarve - Kaupallisessa järjestelmässä on huomioitava tietokantatuotteiden mahdolliset lisenssimaksut. Mikäli tietokanta myydään tuotteen yhteydessä, on tuotteen myyntihinnan oltava selvästi suurempi kuin tietokantavalmistajalle makset
tava lisenssimaksu. Volyymituotteiden yhteydessä voidaan tietysti sopia esimerkiksi prosenttiperusteisista royalty-maksuista.
Oliotietokanta
Oliotietokannan toteutus sisältää aina kuvauksen tietokoneen muistista levyllä olevaan oliotietokantaan. Erillisten latausrutiinien kirjoittaminen on näinollen tarpeetonta.
Kuvaus perustuu C++-luokista automaattisesti muodostettuun tietokantarakenteeseen.
Jotta jonkin luokan oliot kuvautuisivat tietokantaan, tulee kannan toteutuksesta riippuen
joko periyttää halutuille luokille säilyvyysominaisuudet {persistence) valmistajan antamasta yläluokasta tai huomioida säilyvyys olioiden luomisvaiheessa.
Parhaimmillaan oliotietokanta toimii läpinäkyvästi keskusmuistin jatkeena. Ohjelman käynnistyksen yhteydessä haetaan symbolisen nimen avulla osoitin yhteen oliotietokannassa olevaan olioon. Tämän olion sisältämien viittausten avulla voidaan suoraan käsitellä muita tietokannassa olevia olioita. Tehokkaan muistinhallinnan avulla voidaan oliot ladata keskusmuistiin sillä hetkellä, kun niihin ensimmäisen kerran viitataan. Muutokset voidaan tehdä suoraan muistissa oleviin tietorakenteisiin.
Transaktion lopetuksen yhteydessä muutokset tallettuvat oliotietokantaan fyysiseen massamuistiin. Tämäntyyppisen toiminnallisuuden tarjoaa esimerkiksi ObjectStore- oliotietokanta [Obje92].
Oliotietokannat eivät kovin hyvin tue C++-luokkarakenteen muutoksia. Kun jonkin C++-luokan sisäistä rakennetta muutetaan, täytyy koko tietokantarakenne päivittää.
Helpoissa tapauksissa järjestelmä osaa siirtää vanhan tietokannan sisällön uuteen tietokantaan, mutta suuremmissa muutoksissa joudutaan kirjoittamaan siirtoa varten erillinen ohjelma. Mikäli tietokannan rakenne muuttuu usein, joudutaan yhteensopivuuden takaamiseksi kirjoittamaan ja ylläpitämään useita siirto-ohjelmia.
Keskusmuisti
Tietokanta voidaan myös rakentaa kokonaan keskusmuistissa toimivaksi. Tällöin malli talletetaan levylle peräkkäistiedostoon, josta se luetaan latauksen yhteydessä kokonaisuudessaan keskusmuistiin. Keskusmuistissa toimivaa ratkaisua varten on joko kirjoitettava kaikkiin olioluokkiin lataus- ja talletusmetodit (arkistointi) tai vaihtoehtoisesti kuvattava sovellus ohjelmatiedostona. Nämä vaihtoehtoiset tavat käsitellään toteutuksen yhteydessä kappaleessa 5.1.6.
Keskusmuistiin perustuvan ratkaisun interaktiiviset vasteajat ovat pienillä malleilla parhaimmat mahdolliset. Tiedon määrän kasvaessa paljastuvat ilmeiset heikkoudet.
Mallin lataukseen ja tallettamiseen kuluvat ajat ovat suoraan verrannollisia mallin kokoon. Suuren sovelluksen ylläpidosta tulee kankeaa. Ajonaikaiset vasteajatkin romahtavat selvästi siinä vaiheessa, kun ylitetään koneessa olevan keskusmuistin määrä ja joudutaan käyttämään virtuaalimuistia.
Keskusmuistiin perustuvan ratkaisun pahimpiin puutteisiin kuuluu myös sen kyvyttömyys toipua virhetilanteista. Mikäli ohjelman suoritus jostain syystä katkeaa, menetetään välittömästi kaikki keskusmuistissa ollut tieto.
Relaatiotietokanta
Kappaleessa 4.2.2 todettiin, että relaatiotietokannat eivät sellaisenaan sovellu jatkuvasti muuttuvan ja paljon laskennallisia riippuvuuksia sisältävän aineiston hallintaan. Olio
mallissa pitää voida edetä viittauksia pitkin oliosta toiseen, mikä relaatiotietokannassa vaatisi erittäin paljon hakuja ja yhdistelyjä tarpeettoman tehottomasti.
Vertailu
Taulukossa 4 on esitetty eri tietokantavaihtoehtojen vertailu valittujen kriteerien mukaisesti. Relaatiotietokantaa ei arkkitehtuurin ja käsittelyaikojen takia kannata valita.
Oliotietokanta olisi ollut paras ratkaisu, mutta sen ongelmaksi muodostuivat rakenteellisten muutosten vaikea huomioiminen ja valintavaiheen aikainen kallis lisensointipolitiikka. Testattu Obj ectStore-oliotietokanta asetti myös hieman liian suuria laitteistovaatimuksia, esimerkiksi keskusmuistin käytännöllinen minimikoko olisi ollut 24 megatavua.
Taulukko 4 Tietokantavaihtoehtoj en vertailu
Oliotietokanta Keskusmuisti Relaatiotietokanta
Arkkitehtuuri Sopii Sopii Ei oliopohjainen
Kapasiteetti Suuri Pieni Suuri
Virhetilanteiden
Käsittelyajat Lyhyitä Lyhyitä Pitkiä
Rakenteelliset muutokset
Erittäin vaikeita Helppoja riippuen toteutuksesta
Vaikeita Lisenssitarve Kallis tietokanta ja
käyttäj äkohtainen lisensointi
Ei ajonaikaisia lisenssejä
Melko kallis tieto- kantaja käyttäjä
kohtainen lisensointi
Järjestelmän tietokantavaihtoehdoksi valittiin keskusmuistiin perustuva ratkaisu.
Arkkitehtuuri sopii hyvin eikä käyttöön tarvita erillisiä lisenssejä. Uudet ohjelmaversiot voivat lukea kaikkia aikaisempia tiedostoformaatteja, mikä mahdollisti suurtenkin rakenteellisten muutosten tekemisen ohjelman kehityksen aikana. Erityisesti pitkät lataus- ja talletusajat sekä rajallinen kapasiteetti puoltavat kuitenkin oliotietokannan käyttöönottoa, joka on esitetty tämän työn jatkotutkimussuuntana.
4.4.5 Luokkakirjastot
C++-kielen ANSI-standardi ei sisällä valmista luokkakirjastoa. Ohjelman rakentaja voi kirjoittaa kaikki tarvitsemansa luokat itse tai hankkia käyttöönsä valmiita luokkakirjastoja. Nykyisten kääntäjien mukana toimitetaan yleensä valmistajien tekemät luokkakirjastot, joiden avulla käyttöjärjestelmän perusominaisuuksien ja käyttöliittymärutiinien hallintaa saadaan helpotettua.
Tämän työn toteutuksessa on käytetty kahta luokkakirjastoa. Käyttöliittymän perus
komponentit on saatu C++/Views -luokkakirjastosta [Lian94]. Käyttöliittymä on
periaatteessa siirrettävissä sellaisenaan myös esimerkiksi Unix-, Apple- tai OS/2- käyttöjärjestelmiin, sillä kirjastosta on toteutettu yhteensopivat versiot useille eri käyttö
järjestelmille.
Graafisten verkkojen ja puiden piirtämiseen on käytetty Nokia Tutkimuskeskuksessa kehitettyä IGE - Interactive Graph Editor -luokkakirjastoa [Koms95], Käyttö on ollut hyvin pintapuolista ja ainoana tavoitteena on ollut perusominaisuudet sisältävien näkymien luominen ja käsittely.