Common Lisp -kielestä ja Unix-käyttöjärjestelmästä johtuvat ongelmat

3.2.1 Yleistä

Stratexin kehittämisen aikana uskottiin vahvasti Unix-käytöjärjestelmän yleistymiseen graafisena työasemaympäristönä. Unix sopikin Stratexin käyttöjärjestelmäksi erinomaisesti. Siinä missä Dos oli merkkipohjaisen tekstinkäsittelyn käyttöjärjestelmä, voitiin esimerkiksi vaativaa CAD-suunnittelua tehdä ainoastaan Unix-tyyppisissä ympäristöissä. Loppukäyttäjä määrää lopulta ohjelmiston vaatiman käyttöjärjestelmän.

Stratex-ohjelmiston kohdalla todettiin yksiselitteisesti, että järjestelmälle ei riittänyt tarpeeksi asiakkaita UNIX-käyttöjärjestelmässä. Dos/Windows-työasemissa toimivan järjestelmän rakentaminen nähtiin ainoana kaupallisesti kannattavana vaihtoehtona.

Lisp on tänäkin päivänä erinomainen vaihtoehto Unix-ympäristöön tehdyn ohjelmiston toteuttamiseksi. Ajonaikainen Lisp-ympäristö osaa suoraan hyödyntää moniajoa ja tehokasta muistinhallintaa. Toisaalta nykyinen Dos/Windows-käyttöjärjestelmä ei anna riittävää tukea Lisp-sovelluksille. Muutamia Lisp-tulkkeja voidaan periaatteessa käyttää, mutta laajalle levinneistä perussovelluksista ei toistaiseksi ole tietoa. Käytetty ohjelmointikieli on kuitenkin toisarvoinen seikka ohjelmiston varsinaiselle loppu­

käyttäjälle. Tässä kappaleessa esitettävät ongelmat vaikuttivat osaltaan Lisp-kielen hylkäämiseen järjestelmän toteutuksessa käytettävänä ohjelmointikielenä.

3.2.2 Käyttöliittymän rakentamisen vaikeus

Interaktiivinen mallinnusjärjestelmä asettaa suuria vaatimuksia käyttöliittymän toteutukselle [Paaj87]. Ohjelmiston käytön tulee vastata käyttäjän luonnollista käsitystä suoritettavista toiminnoista. Harvoin järjestelmää käyttävät tarvitsevat havainnollisia lomakkeita ja hyvin toteutettua suoraopastusta [Juss91], Usein toistuvat, lähes rutiininomaiset tehtävät tuli pystyä suorittamaan ytimekkäiden ja monipuolisten lomakkeiden ja komentojen avulla. Olioiden välisten riippuvuuksien esittäminen oli aina ollut yksi suunnittelujärjestelmien keskeisistä tavoitteista. Käytännössä rakennettavan järjestelmän piti osata piirtää olioita ja riippuvuuksia sisältäviä näkymiä.

Monipuolisen käyttöliittymän rakentamiseen tarvitaan tehokkaita työvälineitä.

Lomakkeet ja muut komponentit tulisi voida kuvata jollain korkeamman tason kuvauskielellä. Kuvauskielen synnyttämistä varten on esimerkiksi Windows- ympäristössä resurssitiedostoja muodostavia apuohjelmia. Kuvauskielen avulla luodut komponentit liitetään varsinaiseen ohjelmistoon selkeän kutsurajapinnan avulla. Stratex- järjestelmän näyttöjä ei voitu suunnitella piirtämällä erillisten apuohjelmien avulla.

Käyttöliittymää varten kirjoitetun koodin määrä kasvaa helposti suureksi. Stratexin ohjelmakoodista yli 90 prosenttia liittyi suoraan käyttöliittymän toiminnallisuuteen.

Käytetty Lucid CommonLisp Window Toolkit mahdollisti interaktiivisen grafiikan ja lomakkeiden luomisen, mutta antoi ohjelmoijan käyttöön liian primitiivisen kuvauskielen. Korkeamman tason piirtorutiinit jouduttiin näinollen kirjoittamaan itse.

Koska kuvaruudulle piirrettäviä näkymiä haluttiin tulostaa myös paperille, jouduttiin piirtorutiineihin toteuttamaan PostScript-kielen muodostamismahdollisuus itse.

Strategisen suunnittelun tavoitteena keskeinen liiketoiminnan tilaa kuvaavien diagrammien esittäminen oli Stratexissa ratkaistu tekemällä tietyt perusdiagrammit omien piirtokäskyjen avulla. Käytännössä esimerkiksi pylväsdiagrammin esittäminen vaati yksittäisten pikselien ja viivojen piirtämistä. Sisäänrakennettujen graafisten näkymien ongelmia ovat niiden ulkoasun viimeistelemisen ja tulostamisen vaikeus.

Samalla kun kaupallisia ohjelmistoja kehitetään laajoilla resursseilla, oli Stratexin mahdotonta pysyä kehityksen vauhdissa mukana.

Käyttöliittymän testaus voi joskus osoittautua hankalammaksi kuin varsinainen rakentaminen. Uuden piirteen lisääminen voi sivuvaikutuksenaan aiheuttaa virheen aiemmin jo testattuun toimintoon. Monipuolisissa järjestelmissä automaattinen testaus on ainoa tehokas tapa varmistaa järjestelmän toiminta mielivaltaisten operaatioiden aikana [Rämö94]. Stratex-järjestelmän yhteydessä ei käytetty käyttöliittymän kautta tapahtuvaa automaattista testausta.

3.2.3 Liittymät muihin sovelluksiin

Kohteena oleva asiakasryhmä, strategisen suunnittelun päättäjät, käytti lähes yksinomaan mikrotietokoneita ja näiden perusohjelmistoja: taulukkolaskentaa ja tekstinkäsittelyä. Tietojen siirtäminen piti tehdä siirtotiedostojen avulla siten, että otos talletettiin Unix-järjetelmän levylle, josta se edelleen luettiin Dos/Windows-järjestelmän taulukkolaskentasovellukseen. Raporttien lopullinen muotoilu piti tehdä taulukkolaskin- työkalussa manuaalisesti erikseen jokaiselle raportille. Heikko integrointi taulukko­

laskimiin teki analysointikäytön tutun rajapinnan kautta mahdottomaksi.

Suoria tietokantaliittymiä ei Stratexiin saatu koskaan rakennettua. Unix-järjestelmä ei sisällä standardoitua rajapintaa SQL-tietokantoihin, eivätkä resurssit riittäneet toimittajakohtaisten rajapintojen tukemiseen. Periaatteessa suuri osa järjestelmän tiedoista olisi voitu lukea sisään tietokantarajapintojen kautta, mutta resurssi syistä pitäydyttiin tekstipohjaisessa tiedonsiirrossa.

3.2.4 Laitteistovaatimukset

Lisp-kielinen ohjelmisto vaatii erittäin tehokkaan työaseman. Keskusmuistin kokovaatimus on suuri, koska pelkkä ajonaikainen ympäristö tarvitsee noin 10-20 MB muistia. Lisp-kielen muistinhallinta helpottaa ohjelmien rakentamista. Ohjelman ei tarvitse huolehtia väliaikaisten olioiden ja muiden tietorakenteiden tilan vapaut­

tamisesta. Automaattinen muistinhallinta voi kuitenkin osoittautua tehottomaksi, mikäli ohjelmointivaiheessa ei kiinnitetä tarpeeksi huomiota väliaikaisiin tietorakenteisiin.

Staattisissa kielissä muistinhallinta joudutaan hoitamaan eksplisiittisesti, jolloin muistin käyttö on aina suunniteltava tarkasti.

Tyypillinen Stratex-sovellus kulutti kaiken koneessa olevan muistin. Syynä tähän oli muistin suuri hinta, yrityksillä ei ollut varaa ostaa ylimääräistä muistikapasiteettia.

Ajettaessa Lisp-kielistä ohjelmaa muistin äärirajoilla, hidastaa automaattinen muistinvapauttaja, Garbage Collector [AbSu85], huomattavasti sovelluksen toimintaa.

Muistin käydessä vähiin keskeytyy sovelluksen toiminta ja aloitetaan muistinpuhdistus.

Koska keskeytykset toistuvat aktiivisessa käytössä useasti, vaadittiin käyttäjiltä kärsivällisyyttä strategisen suunnittelun kriittisimpinä hetkinä.

Lisp on peruslähtökohdaltaan tulkattava ohjelmointikieli. Ohjelmaa ei voida kokonaan kääntää konekieliseksi, joten ajonaikana joudutaan tulkkaamaan ohjelmakoodia. Tämä asettaa vaatimuksia tehokkaalle prosessorille.

Stratex-sovellus ladattiin aina kokonaisuudessaan keskusmuistiin, ennenkuin sitä voitiin tarkastella. Talletusformaattina käytettiin Lisp-syntaksiin pohjautuvaa määrittelyä, jonka perusteella malli luotiin latauksen yhteydessä uudelleen. Suuren mallin lataus muodostui erittäin hitaaksi. Taulukossa 1 on esitetty kolmen eniten käytetyn sovelluksen latausajat; jokaisen sovelluksen lataus kesti yli tunnin, pisimmillään noin kolme tuntia. Peruskäytössä malli saattoi olla ladattuna keskusmuistiin useita viikkoja.

Ongelmaksi muodostui haluttomuus tehdä kokeilevia muutoksia sovelluksen perustietoihin. Haluttaessa vertailla useita rakenteellisesti suuria muutoksia, oli yli tunnin pituinen latausaika vertailujen välillä liian pitkä.

Taulukko 1 Esimerkkisovelluksia

Yritys Muisti Prosessori Mallin koko, instans­

sien lukumäärä

Mallin latausaika

Outokumpu 48MB PowerPC n. 2000 n. 2 tuntia

Nokia Data 48MB SparcStation 2 n. 1500 n. 1 tunti

Neste 16MB SparcStation 1 n. 1000 n. 3 tuntia

Suurissa konserneissa ei yksittäisen tietokonelaitteiston kustannus suhteutettuna mahdollisesti saataviin hyötyihin luonnollisestikaan estänyt projektien käynnistämistä.

Kalliit alkukustannukset karsivat kuitenkin potentiaalisista asiakkaista pois pienet ja keskisuuret yritykset sekä yksittäiset yrityssuunnittelua tai kansantaloudellista mallin­

tamista tekevät asiantuntijat.

3.2.5 Lisp-järjestelmän ohjelmistonkehityksen apuvälineet

Prototyyppilähestymistavan mukaisesti rakennettu Lisp-ohjelmisto muuttui kokemusten mukaan hankalaksi ylläpitää ohjelman koon kasvaessa. Dynaamisessa ympäristössä oli vaikea muistaa kaikkia ohjelman suoritukseen vaikuttavia asioita. Vaikka Lisp- ohjelmien virheenetsintäominaisuudet {debugging) olivatkin monipuoliset, ei loppu­

aikoina voitu enää täydellä varmuudella selvittää, miten ohjelman suoritus pitkähköissä operaatioissa oikein eteni.

Ajo- ja testiympäristö saattoivat vaihdella suuresti: Stratexia voitiin periaatteessa ajaa usean Unix-käyttöjäijestelmän päällä, kunhan vain käytetystä Lucidin CommonLispistä oli ko. käyttöjärjestelmää tukeva versio. Erilaisten ajoympäristöjen takia saattoi ohjelmassa esiintyvän virheen löytämiseen kulua hyvinkin pitkiä aikoja. Toisinaan virheiden aiheuttajaksi todettiin lopulta yhteensopimattomat käyttöjärjestelmän ja Lispin versiot. Ohjelman rakentajien kannalta työkaluissa esiintyvät viat aiheuttivat oikeutetustikin turhautuneisuutta.

Käytännön tuloksena kaikkia Stratexissa esiintyneitä vikoja ei koskaan saatu paikallistettua. Osassa vioista voitiin käytetty Lisp ja sen kyseinen versio osoittaa syylliseksi, mutta jotkut ongelmat saatiin toistettua ainoastaan tietyllä Unix- käyttöjärjestelmän ja Lisp-tulkin yhdistelmällä.