Design and implementation of a functional object-oriented application development system

TEKNILLINEN KORKEAKOULU Tietotekniikan osasto

Tietotekniikan koulutusohjelma

Teemu Lehto

Funktionaalisen oliopohjaisen sovelluskehittimen suunnittelu ja toteutus

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 28.11.1995.

Työn valvoja:

Työn ohjaaja:

Professori Markku Syrjänen DI Martti Paajanen

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä: Teemu Lehto

Työn nimi: Funktionaalisen oliopohjaisen sovelluskehittimen suunnittelu ja toteutus

Päivämäärä: 28.11.1995 Sivumäärä: 132 Osasto: Tietotekniikan osasto/TT C¿_-

Professuuri: Tik-93, Tietämystekniikka Työn valvoja: Prof. Markku Syrjänen Työn ohjaaja: DI Martti Paajanen

Työssä suunniteltiin ja toteutettiin funktionaalinen oliopohjainen sovelluskehitin.

Sovelluskehitin sisältää oliopohjaisen mallinnusympäristön, jossa voidaan interaktiivisesti muuttaa sovelluksen luokkahierarkiaa ja luokkien sisältöä. Sovelluksen sisältämistä luokista voidaan luoda instansseja, joilla on omat arvonsa kaikille luokassa määritellyille attribuuteille. Kaikki attribuutit ovat tyypitettyjä. Tietoalkioiden tyypit määrittelevät fyysisen talletusmuodon. Assosiaatiot mallitetaan relaatioina, joihin voidaan liittää instanssitasolla tyyppimäärittelyjen mukainen määrä kohdeluokan instansseja.

Sovelluskehittimeen rakennettiin funktionaalinen laskentasääntömekanismi, jonka avulla kuvataan sovelluksen osien väliset laskennalliset riippuvuudet. Laskentasäännöt määritellään luokkien attribuuteille ja ne periytyvät alaluokille ja instansseille.

Laskennan suorittamista varten rakennettiin oliopohjaisiin jäsennyspuihin perustuva ohjaus- ja laskentamekanismi, joka laskee viivästetysti kaikki muutoksista riippuvat arvot.

Työ on jatkoa Nokia Tutkimuskeskuksessa aloitetulle strategisen suunnittelun tukiprojektille. Projektissa oli aikaisemmin tuotteistettu Stratex-niminen sovellus- kehitin, joka perustui Common Lisp -kieleen ja toimi UNIX-käyttöjärjestelmässä. Tässä työssä tuodaan esiin Stratex-järjestelmän heikkouksia ja perustellaan tarvetta rakentaa kokonaan uusi järjestelmä. Samalla kartoitetaan toteutusvaihtoehtoja ja lopulta valitaan toteutuksen ohjelmointikieleksi C++.

Järjestelmän avulla on rakennettu useita asiakaskohtaisia sovelluksia. Saatujen kokemusten perusteella järjestelmä on hyvin vastannut asetettuja tavoitteita.

Onnistuneen käyttöliittymävalinnan ansiosta on voitu rakentaa myös sellaisia raportointisovelluksia, joita alkuperäisissä tavoitteissa ei oltu huomioitu. Jatkokehitys- mahdollisuuksia on useita ja niitä on käsitelty työn loppupuolella.

Avainsanat: Funktionaalinen, oliopohjainen, sovelluskehitin, C++, päätöksenteon tukijärjestelmä

HELSINKI UNIVERSITY OF TECHNOLOGY

ABSTRACT OF THE MASTER’S THESIS

Author: Teemu Lehto

Name of the thesis: Design and implementation of a functional object-oriented application development system

Date: 28.11.1995 Number of pages: 132

Faculty: Faculty of Information Technology Professorship: Tik-93, Knowledge engineering Supervisor: Professor Markku Syrjänen Instructor: M.Sc. Martti Paajanen

In this thesis a functional object-oriented application development system was designed and implemented. The system includes an object-oriented modelling environment, where one can interactively modify the class hierarchy and the contents of the classes.

Instances can be created from user-defined classes. Each instance has its own values for all attributes defined in the instance's base class. All attributes are typed. The type of a knowledge item determines the physical storage needed for its value. Associations are modelled with relation attributes, whose type determines the class and maximum possible amount of related instances.

The application development system contains a functional calculation rule mechanism, which is used to describe the calculational dependencies in the model. Calculation rules are defined for attributes of the classes and they are inherited by sub-classes and instances. To perform the actual calculations a control and execution mechanism based on object-oriented parsing trees was built. Storing of the invalidation information makes it possible to delay the calculations until the values are needed.

This work continues the project for creating a system to support in strategic planning.

The original project was started at the Nokia Research Center and had already delivered a system called Stratex, which was built using Common Lisp on the UNIX operating system. In this work, the weaknesses of Stratex are given as reasons to build a completely new system. Various options for the realization are compared and finally C++ is chosen as the best programming language to use.

The implemented system has been used to build several applications for customers.

According to the experience gathered, the system has met its objectives. The successful choice of user interface has even made it possible to create reporting applications which were not the main target of the system. There are many future development options, some of which are described in the last section of this work.

Keywords: Functional, object-oriented, application development system, C+ + , decision support system

ESIPUHE

Tämä työ on tehty ViSolutions Oy:ssä MU ST-ohj elmiston suunnittelu- ja kehitysprojektin puitteissa. Alunperin Nokia Tutkimuskeskuksessa käynnistetyn projektin tarkoituksena on ollut rakentaa kaupallinen sovelluskehitin päätöksenteon tukijärjestelmien tekemiseen. Teknologian kehittämiskeskus TEKES ansaitsee kiitokset rahallisesta tuesta koko projektin ajalta.

Kiitän ViSolutions Oy:tä käyttööni saamista resursseista ja toimitusjohtaja Juha Hynystä projektia kohtaan osoittamasta mielenkiinnosta. Erityisesti haluan kiittää ohjaajaani DI Martti Paajasta neuvoista ja ohjeista työn kirjoittamiseksi sekä monista mielenkiintoisista keskusteluista rakennetun järjestelmän ominaisuuksista. Sami Rosendahlia kiitän hänen osuudestaan rakennetun järjestelmän tuotteistuksessa. Lisäksi esitän parhaimmat kiitokseni kaikille MUST-projektiin osallistuneille ja samalla tähän diplomityöhön vaikuttaneille henkilöille. Työni valvojana toiminutta professori Markku Syrjästä kiitän avusta työni saattamisessa lopulliseen asuunsa.

Lopuksi esitän kiitokset vaimolleni Mialle työni kirjoittamisen aikana saamastani tuesta.

Espoossa, 28 marraskuuta 1995

Teemu Lehto

KÄYTETYT LYHENTEET

DLL

DDE ODBC

MUST MOS CLOS SQL ROMS TOP OOP

Dynamically Linked Library, ajonaikaisesti sidottava funktiokirjasto, DLL:n avulla ohj emät voivat suoraan kutsua muissa moduleissa sijaitsevia funktioita.

Dynamic Data Exchange, Windows-käyttöjärjestelmän merkkipohjainen viestinvälitysmekanismi.

Open Database Connectivity, Yleiskäyttöinen rajapinta relaatiotieto­

kantoihin, jokainen toimittaja tarjoaa standardoidun rajapinnan mukaisen ODBC-ajurin omaan tietokantaansa.

Multi-Purpose System Modelling Tool, tässä työssä rakennettavan sovelluskehittimen nimi.

MUST Object System, tässä työssä rakennettavan oliojärjestelmän nimi.

Common Lisp Object System, LISP-ohjelmointikieleen rakennettu oliolaaj ennus.

Structured Query Language, standardoitu merkkipohjainen kyselykieli relaatiotietokantoihin.

Relational Database Management System, relaatiotietokannan hallintaohj elmisto.

Type Oriented Programming, Jukka Berqvistin väitöskirjassa esitetty tyyppien käyttöön perustuva ohjemointityyli

Object-Oriented Programming, ohjelmointityyli, jossa ohjelman tietorakenteet on kuvattu olioina ja toiminnallisuus olioihin liittyvillä metodeilla

SISÄLLYSLUETTELO

1 JOHDANTO... 1

2 JÄRJESTELMÄLTÄ VAADITTAVAT OMINAISUUDET... 4

2.1 Oliomallinnusominaisuudet...4

2.1.1 Oliot ja olioluokat...4

2.1.2 Linkit ja assosiaatiot... 5

2.1.3 Luokkahierarkiat j a periytyminen...8

2.2 Laskennalliset ominaisuudet... 10

2.2.1 Yleistä... 10

2.2.2 Laskentasäännöt...11

2.2.3 Laskennan suorittaminen... 12

2.2.4 Laskennan ohjaus... 12

2.3 Sovelluskehitinominaisuudet... 14

2.3.1 Yleistä... 14

2.3.2 Käyttöliittymä... 15

2.3.3 Taulukkonäkymät... 15

2.3.4 Ylläpidettävyys... 16

2.3.5 Sovellusaluekohtaiset vaatimukset...16

2.4 Toteutuksen tehokkuus ja käyttöympäristö...17

3 STRATEX-TOTEUTUS JA SEN ONGELMAT...19

3.1 Stratex-järjestelmän kuvaus... 19

3.1.1 Käyttötarkoitus... 19

3.1.2 Arkkitehtuuri... 19

3.1.3 Tyyppisuuntautunut ohjelmointi...20

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

3.2.1 Yleistä...22

3.2.2 Käyttöliittymän rakentamisen vaikeus... 22

3.2.3 Liittymät muihin sovelluksiin...23

3.2.4 Laitteistovaatimukset...23

3.2.5 Lisp-järjestelmän ohj elmistonkehityksen apuvälineet... 24

3.3 Toteutuksen ongelmat...25

3.3.1 Tyyppiorientoitunut lähestymistapa...25

3.3.2 Olioiden väliset viittaukset...27

3.3.3 Sovelluskehitinominaisuuksien puuttuminen... 27

3.3.4 Lisp-syntaksin mukainen laskentasääntökieli... 28

3.3.5 Suurten asiakkaiden vaatimukset...29

4 VAIHTOEHTOISET LÄHESTYMISTAVAT...30

4.1 Stratex-järjestelmän siirtäminen Dos/Windows-ympäristöön...30

4.2 Sovellusten toteuttaminen kaupallisilla sovelluskehittimillä...30

4.2.1 Taulukkolaskimet... 30

4.2.2 Relaatiotietokannat... 31

4.3 Ohjelmointikielten vertailu... 32

4.3.1 Lisp... 32

4.3.2 SmallTalk... ,.33

4.3.3 C++... 33

4.3.4 Yhteenveto ohjelmointikielistä...34

4.4 Toteutusvaihtoehdot C++-kielellä...35

4.4.1 Oliomallinnusominaisuudet... 35

4.4.2 Evaluointiominaisuudet... 36

4.4.3 Tyyppiorientoituneisuus... 36

4.4.4 Tietokantaratkaisu... 37

4.4.5 Luokkakirjastot... 39

4.5 Käytettävä oliopohjainen metodologia...40

5 TOTEUTETTU JÄRJESTELMÄ... 42

5.1 Ajonaikainen oliomallinnusympäristö - MOS...42

5.1.1 Yleistä...42

5.1.2 Oliomalli...46

5.1.3 Instanssit j a luokat... 47

5.1.4 Attribuutit...49

5.1.5 Periytyminen... 52

5.1.6 Lataaminen ja tallettaminen tiedostoon...56

5.1.7 T yyppisuuntautuneet piirteet... 57

5.2 Funktionaalinen laskentalogiikka... 59

5.2.1 Yleistä... 59

5.2.2 Laskentasäännön määritelmä...59

5.2.3 Laskentasäännön jäsentäminen ja evaluoiminen...60

5.2.4 Riippuvuustiedon välittäminen...68

5.2.5 Laskennan suorittaminen...70

5.2.6 Laskennan ohj aus - j ärj estelmän dynaaminen malli...71

5.2.7 Funktioiden rekisteröiminen...75

5.3 Sovelluskehitinominaisuudet... 75

5.3.1 Käyttöliittymä... 75

5.3.2 Rakennettavien sovellusten ominaisuudet...78

5.3.3 Liittymät muihin järjestelmiin...81

6 JÄRJESTELMÄSTÄ SAADUT KOKEMUKSET...84

6.1 Vertailu tavoitteisiin... 84

6.1.1 Oliomallinnusominaisuudet... 84

6.1.2 Laskentasääntökieli...86

6.1.3 Sovelluskehitintavoitteet... 88

6.1.4 Järj estelmän suorituskyky... 90

6.2 Vertailu Lisp-toteutukseen... 96

6.3 Esimerkkejä soveltamisesta... 98

6.3.1 Asiakasprojektit...98

6.3.2 Asiantunti]ajärjestelmäkehitin ja tekoälykieli... 102

6.3.3 Päättely j a laskenta temporaalilogiikassa... 104

6.3.4 Algoritmien toiminnan havainnollistaminen... 105

6.4 Toteutuksen oikeellisuuden todistaminen... 108

7 JATKOKEHITYSSUUNNAT... 110

7.1 Tuotteistaminen... 110

7.2 Oliotietokannan käyttö... 110

7.3 Optimointiominaisuuksien lisääminen... 111

7.4 Intervallilaskennan liittäminen... 111

7.5 Merkkipohjaisen kyselykielen toteuttaminen... 112

VIITTEET... 114

LIITE A LASKENTASÄÄNTÖKIELEN SYNTAKSI...117

LIITE В OPERAATIOIDEN LASKENTAJÄRJESTYS... 118

LIITE C LASKENTASÄÄNTÖKIELEN FUNKTIOT... 119

LIITE D TOTEUTETTU TAULUKKOMÄÄRITTELYKIELI TFC...124

LIITE E ASIAKASPROJEKTIEN KUVAUKSIA... 126

LIITE F MOS-YTIMEN LUOKKIEN TILANTARVE... 129

1

JOHDANTO

Taustaa

Tietotekniikkaa pyritään nykyisin soveltamaan mahdollisimman laajasti liike-elämän toimintojen apuna. Perustehtäviin, kuten tekstinkäsittelyyn ja taulukkolaskentaan, on kehitetty yleiskäyttöisiä ja monipuolisia ohjelmistoja. Harvinaisempiinkin tarpeisiin on mahdollista löytää valmisohjelmistoja, jotka monipuolisesti kattavat soveltamisalueen yksityiskohdat.

Operatiiviset tietojärjestelmät tuottavat paljon perustietoa, jota halutaan yrityksissä seurata ja analysoida erilaisista näkökulmista. Toteutuneiden lukujen ja omien ennusteiden avulla haluttaisiin myös tarkastella mahdollisia tulevaisuuden skenaarioita.

Jokaisen yrityksen harjoittama liiketoiminta ja sen yhteydessä tehtävät yksityiskohtaiset päätökset poikkeavat toisistaan. Näinollen ei ole mahdollista luoda kaikkia yrityksiä tai toimialoja kattavaa suunnittelujärjestelmää. Tämän työn aiheena oli suunnitella ja toteuttaa sovelluskehitin, jolla voitaisiin tehokkaasti rakentaa asiakaskohtaisia suunnitteluj ärj estelmiä.

Asiakaskohtaisen suunnittelujärjestelmän rakenne ja tietosisältö esitetään käsitemallin {conceptual model) avulla. Oliomallinnuksen keinojen avulla tehdyssä käsitemallissa kuvataan kaikki järjestelmän sisältämät tiedot olioluokkina ja näiden attribuutteina.

Asiakaskohtaiset tiedot syötetään käsitemallin luokista luotujen instanssien attribuuttien arvoiksi. Attribuuttien väliset laskennalliset riippuvuudet kuvataan selväkielisinä laskentasääntölausekkeina ja ovat osa käsitemallia. Suunnittelujärjestelmän tehtävä on laskea mallin kaikkien johdettujen attribuuttien arvot käsitemallin mukaisten laskentasääntöjen avulla. Lopulliseen järjestelmään on lisäksi rakennettava monipuolinen käyttöliittymä, jonka kautta voidaan syöttää tietoja ja tarkastella tuloksia useista eri näkökulmista.

Historia

Nokia Tutkimuskeskuksessa oli jo vuonna 1986 aloitettu projekti päätöksenteon tukijärjestelmän rakentamiseksi. Tarkoituksena oli luoda järjestelmä, jossa reaalimaailmassa esiintyvä, laskennallisia riippuvuuksia sisältävä kokonaisuus olisi voitu kuvata oliomallina. Järjestelmän avulla haluttiin kokonaisuutta tarkastella erilaisista näkökulmista ja tutkia muutosten vaikutuksia kokonaisuuden eri osiin.

Järjestelmästä oli rakennettu kaksi versiota ennen tämän työn alkua, kuva 1.

Ensimmäinen versio oli alkuperäisten ideoiden prototyyppi, joka rakennettiin Symbolics-laitteistojen avulla. Prototyypistä saatujen kokemusten perusteella päätettiin järjestelmästä tehdä kaupallinen tuote.

Varsinaiseksi ohjelmistotuotteeksi asti rakennettiin Stratex-niminen ohjelmisto, joka perustui CommonLisp-kieleen ja vaati Unix-käyttöjärjestelmän. Stratex-ohjelmiston avulla toteutettiin kymmenen suunnittelumallia suurille suomalaisille yrityksille.

Laaj impia käyttöönotettuja sovelluksia olivat Outokumpu-konsernin strategisen suunnittelun avuksi rakennettu monikansallisen kaivosyhtiön malli [NiPa93], Neste Oy:n jalostamojen ja varastojen simulointisovellus sekä Nokia Datan strategista suunnittelua varten rakennettu tytäryhtiöt ja osastot sisältävä suunnittelumalli.

Vaikka Stratex sai kansainvälistäkin tunnustusta (DSS '91: Outstanding New Product of 1991), ei se kuitenkaan menestynyt kaupallisesti. Ohjelmistossa oli puutteita, joita ei voitu ratkaista ohjelmistoa edelleen kehittämällä. Koska ala kuitenkin nähtiin houkuttelevana, päätettiin ohjelmistosta rakentaa vielä kolmas versio, nimeltään MUST - Multi Purpose System Modelling Tool. Ohjelmistolle asetettuja tavoitteita laajennettiin kautta linjan Stratex-järjestelmän tavoitteista. Mukaan otettiin myös kokonaan uusia tavoitteita, erityisesti monia sovelluskehitinominaisuuksia.

Alkuperäiset tavoitteet (86)

* mallinnusympäristö

* strateginen suunnittelu

Laajennetut tavoitteet (93)

* sovelluskehitinominaisuudet

-^Symbolics (87))---) STRATEX (90-94)

MUST - Multi Purpose System Modelling Tool

(93-)

Kuva 1 Päätöksenteon tukij ärj estelmäprojektin historia Tavoitteet

Tämän työn tavoitteena oli suunnitella ja toteuttaa edellä mainittu funktionaalinen, oliopohjainen sovelluskehitin. Sovelluskehittimen avulla oli voitava tehokkaasti rakentaa asiakaskohtaisia suunnittelujärjestelmiä. Sovelluskehittimen oli sisällettävä oliopohjainen mallinnusympäristö suunnittelujärjestelmän käsitemallin luomista ja ylläpitoa varten. Funktionaalisilla ominaisuuksilla tarkoitettiin erillisen laskentasääntökielen määrittelyä ja sen avulla tapahtuvaa laskennan ohjausta ja suorittamista. Järjestelmän oli myös mahdollistettava kaupallista tasoa olevien graafisten käyttöliittymien rakentaminen asiakaskohtaisille suunnittelujärjestelmille.

Rakennettavalle ohjelmistolle asetettavat yksityiskohtaiset vaatimukset oli tarkennettava järjestelmän suunnitteluvaiheessa ja ne on kirjattu osaksi tätä työtä.

Ohjelmiston määrittely- ja suunnitteluvaiheessa voitiin käyttää hyväksi Stratex- ohjelmistosta saatuja kokemuksia. Stratex-j ärj estelmä asetti myös tavoitteita rakennetulle ohjelmistolle. Kaikki Stratex-sovellukset oli voitava siirtää rakennetulle ohjelmistolle siten, että olennaisia toiminnallisuuteen vaikuttavia osia ei tarvinnut jättää pois.

Tässä työssä oli vertailtava erilaisia toteutustapoja järjestelmän rakentamiseksi.

Käytettävä ohjelmointikieli oli valittava siten, että se tukisi mahdollisimman hyvin kaikkia, joskus ristiriitaisiakin tavoitteita. Käyttöjärjestelmäksi oli jo työn alkuperäisenä tavoitteena määrätty Microsoft Windows [Micr92], Erityistä huomiota oli kiinnitettävä järjestelmän toteutukseen liittyviin valintoihin. Eri toteutusvaihtoehdot oli mahdol­

lisuuksien mukaan kuvattava ja samalla oli pyrittävä selvittämään kunkin vaihtoehdon hyvät ja huonot puolet.

Tähän työhön oli kerättävä kokemuksia järjestelmän käyttöönotosta ja rakennetuista asiakaskohtaisista sovelluksista. Esimerkkisovellusten avulla pyritään selvittämään järjestelmän ilmaisuvoimaa erityyppisissä tilanteissa. Sovelluskehitintä ei voida käyttää, mikäli sen ilmaisuvoima ei riitä asiakaskohtaisen sovelluksen rakentamiseksi. Asiakas- projektien kuvauksissa tutkitaan oliopohjaisten ja deklaratiivisten menetelmien sopivuutta nykyisille markkinoille sekä yrityksien valmiuksia soveltaa näitä tekniikoita käytännön projekteissa.

Tietokoneohjelma ei varmaankaan voi täyttää kaikkia sille asetettavia tavoitteita.

Erilaiset asiakaskohtaiset sovellusalueet ja tietotekniikan jatkuva kehittyminen asettavat aina suuren joukon toiveita toteutettaviksi piirteiksi. Jatkokehityssuuntiin on kirjattu ne suunnittelun ja toteutuksen aikana esille tulleet rakenteelliset vaihtoehdot, joiden toteuttaminen voidaan perustella hyvin. Lisäksi on pyritty selvittämään uusien ja odotettavissa olevien tietotekniikan kehityssuuntien hyväksikäyttöä jatkokehityksessä.

Työn tavoitteisiin kuului vielä järjestelmän markkinatilanteen ja odotettavissa olevan elinkaaren hahmottaminen.

Rajaukset

Tähän työhön ei kuulunut rakennettavan järjestelmän kaupallinen tuotteistus. Ulkopuo­

lelle jäivät näinollen järjestelmän käyttöliittymän ja toimintojen viimeistely, käyttö­

ohjeet ja myynninedistämismateriaali. Tämä työ ei ole rakennettavan järjestelmän järjestelmäkuvaus eikä käyttöopas. Toteutusta kuvattaessa käsitellään tarkemmin vain

niitä ominaisuuksia, jotka ovat tärkeitä tämän työn tavoitteiden kannalta.

Tavoitteena oli rakentaa mahdollisimman yleiskäyttöinen sovelluskehitin erityisesti strategisen suunnittelun tarpeisiin. Erilaisten sovellusalueiden erityispiirteitä ei ole tarkoitus käsitellä kovin laajasti, vaan lähinnä kerrotaan soveltamisesta saatuja kokemuksia.

Työssä ei varsinaisesti pyritty luomaan uutta tieteellistä teoriaa oliomallinnukseen tai funktionaaliseen ohjelmointiin, vaan pikemminkin soveltamaan uusimpia tutkimustuloksia ja menetelmiä kaupallisen tuotteen tekemiseen.

2 JÄRJESTELMÄLTÄ VAADITTAVAT OMINAISUUDET

2.1 Oliomallinnusominaisuudet

2.1.1 Oliot ja olioluokat

Oliot

Oliomallinnuksen tehtävänä on kuvata olioita. Esimerkiksi Mauno Koivisto, Outokumpu Oy, tili 2023 ja tuloslaskelmaraportti ovat olioita. Olio on yksinkertaisesti jotain, jolla on merkitys sovellusalueen asiantuntijalle. Olio määritellään tässä käsitteeksi, abstraktioksi tai asiaksi, jolla on selkeä rajapinta ja merkitys mallitettavan kokonaisuuden kannalta. Suuri kokonaisuus voidaan jakaa olioihin usealla tavalla.

Tärkeää on, että jako vastaa asiantuntijan käsitystä reaalimaailmasta ja silti mahdollistaa riittävän tehokkaan tietoteknisen toteutustavan.

Jokaisella oliolla on oma identiteetti. Vaikka kahdella oliolla olisikin täysin samanlaiset ominaisuudet, on ne silti voitava erottaa toisistaan. Tavallisista olio-ohjelmointikielistä poiketen on jokaisella tämän järjestelmän oliolla identiteetin lisäksi yksikäsitteinen nimi. Vaatimus aiheutui siitä, että käyttäjän oli pystyttävä viittaamaan mihin tahansa oliomallin olioon. Ainoa tapa, jolla ihminen voi varmasti erottaa kaksi oliota toisistaan, on antaa niille toisistaan poikkeavat nimet.

Oliopohjaisissa työvälineissä kutsutaan usein lähes kaikkia käyttäjän näkemiä komponentteja olioiksi. Esimerkiksi graafisen käyttöliittymän painonapit, valintalistat ja teksti-ikkunat voivat olla olioita. Sellaista oliota, jonka rakenne määräytyy alla kuvatun luokan perusteella, kutsutaan oliomallinnuksessa myös kyseessä olevan luokan instanssiksi.

Luokat

Olioluokka määrittelee joukon olioita, joilla on samanlainen rakenne (tietoalkiot), samanlaiset suhteet toisiin olioihin (relaatiot), samanlainen käyttäytyminen (operaatiot) ja yhteinen semantiikka. Henkilö, yritys, tili ja raportti ovat olioluokkia. Samaan luokkaan kuuluvilla olioilla on sovelluksen kannalta sama semanttinen merkitys.

Jokainen olio kuuluu täsmälleen yhteen luokkaan. Jotta käyttäjä pystyisi erottamaan luokat toisistaan, on niille annettava yksikäsitteiset nimet.

Luokkien tuli olla sovelluksen kannalta ensimmäisen tason olioita [Stee90] [Paep93], eli sovelluksessa oli voitava viitata olioluokkiin, luoda uusia olioluokkia ja kohdistaa niihin operaatioita. Käyttäjä voi kohdistaa luokkiin ajonaikaisesti kaikkia tässä kappaleessa esille tulevia oliomallinnuksen operaatioita. Esimerkiksi luokan nimeä tulee voida muuttaa, luokalle on voitava lisätä tai poistaa yläluokka, luokalta on voitava kysyä lista

luokkaan kuuluvista olioista, luokkaan on voitava lisätä tai siitä poistaa attribuutteja ja luokan on osattava luoda uusi luokkaan kuuluva olio alustaen se oletusarvoilla.

Tietoalkiot

Tietoalkio on luokan olioille kuuluva tiedon palanen. Liikevaihto, kulut ja tulos voivat olla ynYys-luokan olioiden tietoalkioita. Samassa luokassa ei koskaan saa olla kahta saman nimistä tietoalkiota. Tietoalkioiden arvot ovat instanssikohtaisia; eri olioinstansseilla voi olla samoja tai eri arvoja tietylle tietoalkiolle.

Järjestelmän sisältämien tietoalkioiden tuli olla tyypitettyjä. Tyyppi määrittelee tietoalkion arvon sisäisen talletusmuodon ja semantiikan. Vaihtoehtoisista sisäisistä talletusmuodoista oli toteutettava ainakin merkkijono, luku ja lukulista. Semanttisia ominaisuuksia ovat esimerkiksi aikaan sidotun lukulistan alkuhetki ja listan pituus.

Käyttäjän oli voitava luoda uusia tietotyyppejä rakennettujen sisäisten talletusmuotojen perusteella. Tietoalkion arvo ei koskaan saa olla olio, vaan sen on oltava puhdas arvo.

Puhtailla arvoilla ei ole identiteettiä.

Operaatiot ja metodit

Operaatio on funktio tai toiminto, jota voidaan soveltaa luokkaan kuuluvaan olioon.

Piirrä, siirrä ja väritä ovat luokkaan ympyrä liittyviä operaatioita. Kaikki saman luokan instanssit jakavat samat operaatiot. Operaation ominaisuuksia ovat nimi, paluuarvo ja argumenttilista. Operaatio suoritetaan kutsumalla instanssia operaation nimen avulla.

Instanssi hakee käytettävän operaation omasta luokastaan.

Samaa operaatiota voidaan mahdollisesti soveltaa moneen eri luokkaan. Tällainen operaatio voi olla polymorfmen, jolloin eri luokissa operaatioon voi liittyä erilaisia toimintoja. Operaation implementaatiota yhdelle luokalle kutsutaan metodiksi.

Operaatioita varten rakennettavan funktionaalisen laskentasääntökielen vaatimukset esitetään tarkemmin kappaleessa 2.2.

2.1.2 Linkit ja assosiaatiot

Linkki on fyysinen tai käsitteellinen yhteys olioinstanssien välillä, esimerkiksi Matti työskentelee Outokumpu Oy:ssä. Matemaattisesti määriteltynä linkki on n-tuppeli, eli järjestetty lista olioinstansseja. Assosiaatio määrittelee ryhmän linkkejä, joilla on sama rakenne ja semanttinen merkitys. Linkki on siis instanssi assosiaatiosta samoin kuin olio on instanssi olioluokasta. Luokkien välinen assosiaatio kuvaa joukon potentiaalisia instanssien välisiä linkkejä.

Assosiaatiot ovat yleiseltä luonteeltaan kaksisuuntaisia. Työskentelee-assosiaation nimi toiseen suuntaan edettäessä voisi olla työllistää. Tietomallin kannalta molemmat suunnat ovat yhtä merkityksellisiä ja viittaavat samaan assosiaatioon.

Yleisiä assosiaatioita voidaan määritellä kahden, kolmen, tai useammankin luokan välille. Suurin osa reaalimaailmassa esiintyvistä assosiaatioista on kuitenkin kahden

luokan välisiä. Tässä työssä oli toteutettava ainoastaan binääriset eli kahden luokan väliset assosiaatiot, sillä oliomallinnuksessa voidaan monimutkaisemmat assosiaatiot kuvata luokkien avulla. Assosiaatioiden mallintaminen luokkina on kuvattu tässä luvussa alkaen sivulta 7.

Kardinaliteetti

Kardinaliteetti kertoo, kuinka monta assosiaation toisena osapuolena olevan luokan instanssia voi liittyä toisen pään luokan yhteen instanssiin. Kardinaliteetti rajoittaa siis instanssien välisten linkkien lukumäärää. Yleisesti kardinaliteetti voi olla mielivaltainen joukko positiivisia kokonaislukuja. Esimerkiksi perheauton ovien lukumäärä voi olla joko 2 tai 4. Tärkein rajoitus kardinaliteetissa tehdään yksi- ja monipaikkaisten assosiaatioiden välillä. Yksipaikkaiseen assosiaatioon voidaan liittää joko yksi tai ei yhtään kohdeluokan instanssia. Monipaikkaiseen voidaan vastaavasti liittää instansseja yksi, useita tai ei yhtään.

Assosiaation kardinaliteetissa oli tehtävä ero ainakin yksi- ja monipaikkaisen kardinaliteetin kohdalla. Tarkka kardinaliteetti voidaan toteuttaa raj oitussäännöillä, jotka kertovat virheilmoituksina kardinaliteettiehtojen epäonnistumisesta. Järjestelmän tavoitteissa ei oteta suoraan kantaa assosiaatioiden toteutustapaan. Yleinen tapa on esittää yksipaikkainen assosiaatio osoittimen {pointer) avulla ja monipaikkainen assosiaatio listana liittyneitä olioita. Relaatiotietokannoissa yksipaikkaiset assosiaatiot voidaan esittää suoraan luokkaa vastaavan tietokantataulun sarakkeena. Monipaikkaisia assosiaatioita varten luodaan omat taulut.

Linkkien attribuutit

Tavalliset attribuutit ovat olioluokan instanssien ominaisuuksia. Vastaavasti linkkien attribuutit ovat assosiaatioissa määriteltyjä linkkien ominaisuuksia. Jokaisella linkkiattribuutilla on oma arvo jokaista linkkiä kohti, aivan kuten olioluokassa määritellyllä attribuutilla on arvo jokaista olioinstanssia kohti.

Linkkiattribuutit ovat tarpeellisia silloin, kun linkin olemassaoloon liittyy suhdetta kuvaavia tietoja. Kuvassa 2 on tytäryhtiö-assosiaatioon liitetty konsernin omistussuhde esitetty linkkiattribuuttina. Mikäli useat eri yritykset voivat omistaa tytäryhtiön osakkeita, on kyseessä monesta moneen assosiaatio. Omistussuhde on selkeästi assosiaation ominaisuus, eikä sitä voida tallettaa emo- tai tytäryhtiöön.

'"omistussuhde'

Kuva 2 Omistussuhteen esittäminen linkin attribuuttina

Assosiaatioiden mallintaminen luokkina

Linkkiattribuuttien ja useamman kuin kahden luokan välisten assosiaatioiden toteuttaminen voi olla vaikeaa. Mikäli halutaan käyttää tehokasta esitystapaa — yksipaikkainen linkki osoittimena ja monipaikkainen listana — ei linkkiattribuutteille ole talletuspaikkaa. Ongelma voidaan kuitenkin aina ratkaista kahden luokan välisten assosiaatioiden ja uusien luokkien avulla.

Otetaan esimerkiksi teollisuudesta tuttu tilanne, jossa tehdas myy tiettyä tuotetta tietyille markkinoille. Assosiaatio voitaisiin mallintaa tehdas-, tuote- ja markkina-alue -luokkien välille siten, että assosiaation attribuutteina olisivat myyty määrä ja myyntihinta.

Kaikkien assosiaation päiden kardinaliteetti on monta.

Kuva 3 Kolmen luokan välinen assosiaatio, jolla on omia attribuutteja

Assosiaation mallintamiseen olioluokkana tarvitaan yksi uusi luokka. Otetaan edelliseen esimerkkiin mukaan uusi luokka TehtaanTuotemyyntiMarkkinoille. Linkkiattribuuteista määrä ja hinta tulee nyt uuden luokan attribuutteja. Kolmen luokan välinen assosiaatio korvataan kolmella kahden luokan välisellä assosiaatiolla, joissa toisena päänä on aina assosiaatiota varten luotu uusi luokka.

Tehdas

j

/Tuote ^ T ehtaanT uotemyynti-

Markkinoille

K

määrä hinta

Markkina-alue

Kuva 4 Assosiaation mallintaminen luokkana Roolinimet

Assosiaation yhtä päätä kutsutaan rooliksi. Binäärisessä assosiaatiossa on kaksi roolia, molemmilla voi olla oma roolinimensä. Roolinimi määrittelee yksikäsitteisesti yhden assosiaation pään ko. luokan keskuudessa. Roolinimen avulla lähtöluokan instanssista

voidaan matkustaa kohdeluokan instanssiin tai instansseihin. Roolinimi voidaan ajatella luokan johdettuna attribuuttina, jonka arvo on joukko olioinstansseja.

Roolinimet helpottavat assosiaatioiden käyttöä luokissa. Työskennellä-assosiaation toisen pään roolinimenä voisi olla työnantaja ja toisen pään työntekijät. Hyvin valitut roolinimet kertovat samalla assosiaation kardinaliteetin, työntekijällä voi olla vain yksi työnantaja, työnantajalla taas voi olla useita työntekijöitä. Roolinimien käytön oli oltava mahdollista rakennettavassa järjestelmässä.

Järjestys

Olioiden välisillä linkeillä ei aina ole tarkkaa järjestystä, vaan olioon voidaan ajatella liittyvän joukko kohdeluokan instansseja. Esimerkiksi tytäryhtiöt-assosiaatioon voi kuulua useita yhtiöitä, joiden keskinäisellä järjestyksellä ei välttämättä ole merkitystä.

Suunnittelumalleissa esiintyy kuitenkin hyvin usein tilanteita, joissa tarkkaa järjestystä tarvitaan. Järjestyksen säilyttävien assosiaatioiden mallinnuksen tuli siten olla mahdollista.

Aggregaatit)

Aggregaatio on rakenne, jossa komponentteina toimivat oliot liittyvät kokonaisuutena toimivaan olioon. Aggregaatio täydentää yleistä assosiaatiota määrittelemällä sille erityisen semantiikan. Aggregaatio on transitiivinen (jos A on B:n osa, ja В on C:n osa, niin A on C:n osa) ja antisymmetrinen (jos A on B:n osa, niin В ei ole A:n osa).

Mallinnusteknisesti aggregaatio voidaan toteuttaa tavallisena assosisaationa.

Rakenteellisten rajoitusehtojen avulla oli kuitenkin voitava kuvata kokonaisuuksia, jotka muodostuvat useista olioinstansseista. Mikäli aggregaatioon kuuluva komponentti ei voi olla olemassa ilman kokonaisuutta, on oliolle voitava kirjoittaa rajoitusehto, joka tuhoaa olion kokonaisuuden tuhoutuessa. Sellaiset komponentit, jotka aina kuuluvat kokonaisuuteen, tulisi voida luoda automaattisesti kokonaisuutta luotaessa.

2.1.3 Luokkahierarkiat ja periytyminen

Olioluokkien samankaltaisuutta voidaan luokkahierarkian avulla mallintaa säilyttäen kunkin luokat omat erityisominaisuudet. Yhteisten ominaisuuksien kokoamista yhteen luokkaan kutsutaan yleistämiseksi {generalization). Yleistettyä luokkaa kutsutaan yläluokaksi {superclass) ja tarkennettuja luokkia tämän luokan alaluokiksi {subclass).

Jokaisen alaluokan sanotaan perivän {inherit) yläluokassa määritellyt ominaisuudet.

Perittyjen ominaisuuksien lisäksi alaluokissa voidaan määritellä uusia attributteja ja operaatioita.

Yleistäminen ja periytyminen ovat transitiivisia kaikkien luokkahierarkian tasojen yli.

Epäsuoralla yläluokalla tarkoitetaan välissä olevan luokan kautta perittyä luokkaa.

Edeltäjä {ancestor) on joko suora tai epäsuora yläluokka.

Jokainen instanssi kuuluu johonkin tiettyyn luokkaan, jota kutsutaan instanssin perusluokaksi {base class). Instanssi on samalla kuitenkin myös kaikkien perus­

luokkansa yläluokkien instanssi. Käytännössä instanssilta löytyy arvo jokaiselle edeltäjäluokissaan määritellylle attribuutille.

Periytyminen on voimakas oliomallinnuksen väline, joka strukturoi luokkien joukkoa tuoden samalla esille luokkien väliset samankaltaisuudet ja erilaisuudet. Oliopohjaiset ohjelmointikielet tarjoavat yleensä monipuolisia periytymisominaisuuksia. Yhtenä periytymisen hyötynä mainitaan usein ohjelmakoodin uudelleenkäyttö. Yläluokkiin kirjoitetut operaatiot ovat sellaisenaan käytettävissä alaluokissa.

Perittyjen ominaisuuksien ohittaminen

Alaluokka voi ohittaa {override) yläluokassa määritellyn operaation määrittelemällä sen uudelleen. Tällöin on alaluokassa, sen alaluokissa ja kaikissa instansseissa käytettävä uudelleenmääriteltyä operaatiota. Instanssitasolla ei kuitenkaan ole mahdollista ohittaa luokissa määriteltyjä operaatioita, jolloin jokaisella instanssilla on käytössään täsmälleen perusluokassaan määritellyt operaatiot.

Abstraktit luokat

Luokka on abstrakti, mikäli sillä ei voi olla suoria instansseja. Abstrakti luokka ei periaatteessa voi esiintyä luokkahierarkian lehtenä, sillä silloin sen määrittelemät ominaisuudet eivät voi olla käytössä yhdessäkään instanssissa.

Abstraktien luokkien avulla luokkahierarkiaan saadaan lisää syvyyttä. Yhteisiä ominaisuuksia voidaan koota välissä oleviin abstrakteihin yläluokkiin ja lopulliset operaatiot toteuttaa vasta alaluokissa.

Moniperintä

Moniperintä mahdollistaa useamman kuin yhden suoran yläluokan määrittelemisen luokalle, joka näin perii ominaisuuksia kaikista yläluokistaan. Saavutettavia hyötyjä ovat ilmaisuvoimaisemmat mallinnusmahdollisuudet, koodin suurempi uudelleenkäyttö- mahdollisuus sekä tapa kuvata reaalimaailmassa esiintyviä rakenteita ihmisen ajattelutavan mukaisesti. Haittana on käsitteellisen ja toteutusteknisen helppouden katoaminen, moniperintä aiheuttaa puumaisen luokkahierarkian muuttumisen suunnatuksi graafiksi.

Metadata

Metadata on tietoa, joka kuvaa ja määrittelee toisia tietoja. Esimerkiksi luokkamääritykset ovat metadataa, jolla kuvataan luokasta luotujen instanssien ominaisuuksia. Vastaavasti tietokoneella tehty malli on metadataa, joka kuvaa reaalimaailmassa olevia asioita.

Monissa reaalimaailman sovelluksissa esiintyy metadataa. Sovellus voisi sisältää esimerkiksi tietoja kaikista Suomessa liikenteessä olevista autoista. Jokaisella

yksittäisellä autolla on sarjanumero, rekisterinumero, väri ja omistaja. Jokainen auto on myös tietyn mallinen: esimerkiksi Saab 900 GLi -83 tai Opel Corsa 1.4si GLS -94.

Automalli on metadataa ja kertoo tietyn mallisen auton valmistajan, vakuutusluokat, valmistusvuoden ja ohjehinnan. Rakennettava sovellus sisältäisi näin luokat automalli ja auto. Jokainen auto-luokan instanssi liittyisi täsmälleen yhteen automa/Zz-luokan instanssiin.

Luokkakohtaiset attribuutit

Luokkakohtaisella attribuutilla on yksi yhteinen arvo riippumatta luokasta luotujen instanssien määrästä. Luokkakohtaisiin tietoalkioihin voidaan sijoittaa kaikille instansseille yhteisiä lukuarvoja. Muuttuva luokkakohtainen attribuutti voisi olla esimerkiksi luokasta luotujen instanssien määrä, uuden instanssin luominen kasvattaisi attribuutin arvoa yhdellä.

Johdetut attribuutit ja oliot

Johdettu attribuutti määritellään funktiona yhdestä tai useammasta oliosta tai attribuutista, jotka voivat myös olla johdettuja. Muut objektit määrittelevät täydellisesti johdetun attribuutin arvon. Johdettu attribuutti on redundantti, mutta se esiintyy usein oliomallissa, koska sillä on selkeä reaalimaailman vastine. Esimerkiksi yrityksen tulos voidaan laskea tulojen ja menojen erotuksena, henkilön ikä saadaan syntymäajan ja nykypäivän perusteella. Tuottavat tytäryhtiöt saadaan valitsemalla tytäryhtöistä ne, joiden tulos on positiivinen.

Johdettu olio koostuu täysin johdetuista attribuuteista. Johdetun olion olemassaolokin perustuu muiden olioiden olemassaoloon. Esimerkiksi yrityksen tuloslaskelma on johdettu olio, joka voidaan laskea yrityksen toteutuneen kirjanpidon perusteella.

Konsernituloslaskelma taas on johdettu olio, joka voidaan laskea tytäryhtiöiden tuloslaskelmien avulla. Yksittäinen tuloslaskelma-olio on syytä tuhota, mikäli seurattava yritys poistetaan mallista.

Johdettujen objektien arvo ja olemassaolo kuvataan oliomallissa deklaratiivisesti.

Imperatiivisissa ohjelmointikielissä arvojen laskemiseksi on tehtävä suoritettavaa ohjelmakoodia, jossa uudet arvot asetetaan sijoituslauseiden avulla [Eise87], MUST- sovelluskehittimessä arvojen laskeminen ja laskennan ohjaus perustuvat suoraan oliomalliin liitettyihin deklaratiivisiin lausekkeisiin. Tarvittavat laskennalliset ominaisuudet on esitetty seuraavassa kappaleessa 2.2.

2.2 Laskennalliset ominaisuudet

2.2.1 Yleistä

OMT-metodologian mukaisesti [Rumb91] järjestelmän funktionaalinen malli kuvaa mitä, dynaaminen malli milloin ja oliomalli mille järjestelmässä tapahtuu.

Rakennettavan laskentasääntömekanismin tarkoituksena on toteuttaa sovelluksen funktionaalisen ja dynaamisen mallin vaatimat ominaisuudet.

Funktionaalinen malli kuvaa, miten laskennan lopputulokset saadaan laskettua alkuarvoista ottamatta kantaa yksittäisten arvojen laskentajärjestykseen. Ohjelmointi­

kielen kääntäjä koostuu lähes yksinomaan funktionaalisesta mallista, joka esittää lähdekoodin syntaksista riippuvan kuvauksen ajettavaksi ohjelmaksi. Toisaalta tietokannoissa on usein triviaali funktionaalinen malli, sillä niiden tarkoituksena on tallettaa tietoa, ei muuttaa sitä. Taulukkolaskinlomake on eräänlainen funktionaalinen malli. Taulukkojen soluihin liitetyt lausekkeet kertovat solujen riippuvuudet toisistaan aritmeettisina laskentakaavoina. Funktionaalinen malli on suunnittelujärjestelmissä asiakaskohtainen ja se koostuu malliin liitetyistä laskentasääntölausekkeista.

Dynaaminen malli määrittelee laskentaj ärj estyksen. Deklaratiivisesti esitetyn funktionaalisen mallin laskentaj ärj esty s on periaatteessa mielivaltainen ja laskentaa voidaan suorittaa jopa rinnakkain. Tärkein toiminto on toisistaan riippuvien tietojen uudelleenlaskenta lähtötietojen muuttuessa. Laskentasääntömekanismi määrittelee suurimman osan asiakaskohtaisen suunnittelujärjestelmän dynaamisesta mallista.

Käyttäjän ei tarvitse erikseen määritellä laskentaj ärj esty stä tai käynnistää muuttuneiden tietojen laskentaa. Käytännön sovelluksissa voi kuitenkin esiintyä tarpeita tiettyjen kontrollirakenteiden esittämiseen. Käyttäjän on poikkeustapauksissa voitava vaikuttaa laskentaj ärj estykseen laskentasääntömekanismin avulla.

2.2.2 Laskentasäännöt

Laskentasääntö on objekti, jonka avulla voidaan yksikäsitteisesti laskea mallissa olevan johdetun attribuutin arvo. Jokainen laskentasääntö liittyy yhteen olioluokassa määriteltyyn johdettuun attribuuttiin. Tätä attribuuttia kutsutaan säännön omistaja- attribuutiksi. Jokaisella laskentasäännöllä on lisäksi ainakin nimi ja lauseke.

Nimi identifioi laskentasäännön yksikäsitteisesti ja sen perusteella käyttäjä voi tulkita laskennan aikana mahdollisesti tulostettavia ilmoituksia sekä valita haluamansa säännön useita sääntöjä käsittävästä listasta. Järjestelmä antaa uudelle säännölle oletusarvona yksikäsitteisen nimen, jota käyttäjä voi halutessaan muuttaa.

Lauseke on laskentakielen syntaksin mukainen merkkijono, jolle voidaan laskea yksikäsitteinen arvo. Kielen syntaksin oli oltava helposti ymmärrettävissä ja luettavissa.

Esimerkki mahdollisesta syntaksista on esitetty liitteessä A. Lausekkeessa oli voitava esittää ainakin vakioita, operaattoreita, funktiokutsuja ja viittauksia mallissa esiintyviin instansseihin ja näiden attribuutteihin. Viittaukset mallin komponentteihin oli voitava tehdä valitsemalla valintalistoista. Mallin komponenttien - esimerkiksi attribuuttien - nimien muuttuessa oli laskentasäännön lausekkeen päivityttävä automaattisesti.

Kielen oli sisällettävä riittävä määrä valmiita funktioita sovellusten rakentamiseksi.

Hyvänä esimerkkinä tarvittavista funktioista pidettiin Microsoft Excel - taulukkolaskin- ohjelmistoa [Micr94b], Uusien funktioiden lisäämisen ajonaikaisesti tuli olla mahdollista kokeneelle loppukäyttäjälle. Operaatioina oli toteutettava rajallinen joukko

käyttäjälle tuttuja perusoperaatioita. Uusien operaatioiden lisäämistä ajonaikaisesti ei haluttu sallia.

Laskentasääntökielen tuli kokonaisuudessaan olla polymorfmen [Budd91].

Primitiivisistä laskennallisista tietotyypeistä oli toteutettava ainakin merkkijonot, luvut ja lukulistat. Operaatioiden tuli olla määriteltyjä kaikkien tietotyyppien välille.

Esimerkiksi laskettaessa yhteen lukulista [1 2 3] ja yksittäinen luku 4, on tulokseksi saatava lukulista [5 6 7]. Funktioiden on mahdollisuuksien mukaan hyväksyttävä vaihtoehtoisia primitiivisiä tietotyyppejä argumentteinaan.

Funktioiden tyypitykseen tuli kiinnittää erityistä huomiota. Järjestelmän oli tehtävä tyyppitarkistukset sellaisille argumenteille, joiden tulee olla tietyn tyyppisiä. Mikäli argumentin tyyppi ei ole funktion haluama, on argumentti koetettava muuttaa halutun tyyppiseksi. Funktion haluaman argumentin tyyppi voidaan myös jättää avoimeksi.

Tällöin funktio itse huolehtii polymorfisen argumenttinsa käsittelystä. Funktioita oli myös voitava kutsua vaihtelevalla määrällä argumentteja ja funktioiden oli itse saatava päättää, evaluoidaanko argumentit valmiiksi ennen kutsua.

2.2.3 Laskennan suorittaminen

Johdetun attribuutin arvo oli osattava laskea siihen liitetyn laskentasääntökielisen lausekkeen perusteella. Lausekkeessa esiintyvien attribuuttien arvot tuli hakea suhteellisina lähtien siitä instanssista, jonka attribuutille sääntöä ollaan parhaillaan laskemassa.

Laskennan oli oltava mahdollisimman nopeaa ja käytettävä säästeliäästi keskusmuistia.

Laskennan aikana tapahtuvista virhetilanteista piti pystyä antamaan informatiivisia virheilmoituksia tai varoituksia ja mahdollisuuksien mukaan pyrittävä opastamaan käyttäjää korjaustoimenpiteiden löytämisessä.

2.2.4 Laskennan ohjaus

Sääntöjen avulla kuvatun laskennan tuli tapahtua aina tarpeen tullen mallin sisältämien lukuarvojen tai viittausten muuttuessa. Käyttäjän kannalta katsottuna laskennan oli ajallisesti tapahduttava lähtötietojen muuttumisen ja tulosten tarkastelemisen välissä.

Laskentasääntölauseke määrittelee yksikäsitteisesti joukon perusattribuutteja, joiden arvoista yksittäisen sääntöä käyttävän johdetun attribuutin arvo riippuu. Toteutuksen kannalta oli haastavaa rakentaa mekanismi, joka osaa sääntölauseketta käänteiseen suuntaan tarkastelemalla päätellä kaikki ne attribuutit, joihin yhden perusattribuutin muutoksella on vaikutusta. Esimerkiksi lausekkeen 'Myynti - OmaMyynti + sumfTuotteet.Myynti)' arvo muuttuu instanssissa olevan OmaMyynti-tietoalkion arvon muuttuessa, instanssissa olevan Tuo/teei-relaation arvon muuttuessa tai jonkin ko.

TMøtteef-relaatiossa olevan instanssin Myy/tfz-tietoalkion arvon muuttuessa.

Laskennan ohjaukselle on seuraavat neljä vaihtoehtoa:

1. Lasketaan johdettujen attribuuttien arvot aina tarvittaessa, mutta ei talleteta saatuja tuloksia. Edut: Säästetään tilaa. Ei tarvita invalidointia. Haitat: Tietojen katselu on erittäin hidasta. Koska laskennan aikana esiintyviä välituloksiakaan ei talleteta, saattaa monesta johdetusta attribuutista johdetun attribuutin laskenta kestää vuorokausia.

2. Lasketaan yhdenkin muutoksen jälkeen kaikkille johdetuille attribuuteille uudet arvot ja talletetaan saadut tulokset. Edut: Lasketun mallin tarkastelu on nopeaa. Ei tarvita invalidointia. Haitat: Koko malli joudutaan laskemaan uudestaan, jolloin laskenta saattaa kestää tunteja.

3. Lasketaan jokaisen muutoksen yhteydessä välittömästi uudet arvot kaikille muutetusta attribuutista riippuville attribuuteille. Edut: Ei tarvitse laskea koko mallia. Haitat: Lasketaan turhaan sellaisia lukuja, joiden arvoista käyttäjä ei ole kiinnostunut. Laskenta joudutaan suorittamaan myös peräkkäisten muutosten välissä.

4. Invalidoidaan muutosten yhteydessä kaikki muutetusta attribuutista riippuvat muut attribuutit. Lasketaan tulosten tarkastelun yhteydessä arvot niille invalidoiduille attribuuteille, joiden arvoja kysytään. Edut: Lasketaan vain kulloinkin tarvittavat arvot. Haitat: Toteutuksen kannalta vaikein vaihtoehto.

Tässä työssä oli toteutettava vaihtoehdon 4 mukainen laskennan ohjausmekanismi. Tätä varsin monimutkaista toiminnallisuutta varten oli rakennettava erityinen epäkelpoisuus- tiedon levittämismekanismi, jolla jäsennettyjä laskentasääntölausekkeita takaperin seuraamalla pystytään selvittämään kaikki muutosten aiheuttamat mallin uudelleen- laskentatarpeet. Vaihtoehdon 4 mukainen laskennan ohjaus on siis puskuroitua ja viivästettyä. Puskuroinnilla tarkoitetaan sitä, että jokaisen attribuutin arvo lasketaan valmiiksi ja saatu arvo talletetaan attribuutin arvoksi. Kysyttäessä attribuutin arvoa useita kertoja peräkkäin suoritetaan laskenta tarvittaessa vain ensimmäisellä kerralla.

Koska attribuuttiin itseensä on talletettu sen arvo, tulee tämän arvon paikkansapitävyyttä seurata tarkasti. Talletettu arvo menettää merkityksensä silloin, kun jokin attribuutin arvoon vaikuttava mallin tekjä muuttuu. Tällaisia tekijöitä ovat esimerkiksi tietoalkioiden muuttuneet arvot, instanssien välisissä viittauksissa tapahtuvat muutokset, uusien instanssien, luokkien tai attribuuttien luominen tai tuhoaminen ja instanssien nimien muuttuminen. Kun attribuuttiin talletettu arvo menettää merkityksensä, täytyy arvo laskea uudestaan. Tämä laskenta voidaan kuitenkin tehdä viivästetysti laskemalla arvo vasta sitten, kun arvoa seuraavan kerran attribuutilta kysytään. Attribuutin arvon menettäessä merkityksensä sille ei siis lasketakaan uutta arvoa heti, vaan entinen arvo mitätöidään eli invalidoidaan. Viivästetystä laskennasta saavutetaan seuraavat hyödyt:

• Päivitettäessä malliin useita uusia arvoja, ei päivitysten välissä tarvitse laskea muuttuneista tiedoista riippuvia attribuutteja moneen kertaan.

• Koko malliin vaikuttavan parametrin muutoksen vaikutuksia voidaan tehokkaasti tarkastella haluttujen muuttujien suhteen. Vaikka lähes kaikki mallin attribuutit invalidoituvat, joudutaan vain osan arvo laskemaan uudestaan.

Viivästetty laskenta aiheuttaa seuraavia ongelmia:

• Koska laskentaa ei invalidointivaiheessa todellisuudessa suoriteta, joudutaan kaikki muuttuneista tiedoista mahdollisesti riippuvat attribuutit invalidoimaan, vaikka tietojen muutos ei vaikuttaisikaan näiden arvoihin. Viivästetty mekanismi siis olettaa, että jokainen muutos propagoituu kaikkien riippuvien attribuuttien arvojen muuttumiseen.

• Tietyt sivuvaikutukselle! laskentasäännöt halutaan usein suoritettaviksi heti muutosten tapahduttua. Tällainen sivuvaikutus voi olla esimerkiksi arvon muuttumisesta kertovan viestin tulostaminen käyttäjälle.

Laskentasääntökohtainen laskennan ohjaus

Edellä havaittujen ongelmien ratkaisemiseksi oli laskentaa voitava ohjata laskentasääntökohtaisesti. Yksittäisen säännön laskenta-algoritmi oli voitava valita seuraavista neljästä vaihtoehdosta:

1. Normaali viivästetty laskenta ja invalidointi. Attribuutin arvo invalidoidaan jonkun lausekkeessa tapahtuvan muutoksen jälkeen ja invalidoitumistieto välitetään eteenpäin. Attribuutille lasketaan uusi arvo viivästetysti silloin, kun sitä ensimmäisen kerran tarvitaan.

2. Muutostapahtuman jälkeen välittömästi tapahtuva laskenta, mutta normaali invalidointi. Eroaa edellisestä siinä, että uusi arvo lasketaan välittömästi käyttäjän tekemien muutosten jälkeen.

3. Uuden arvon laskenta ennen invalidoitumistiedon välittämistä. Attribuutin uusi arvo lasketaan välittömästi invalidointitiedon saapuessa. Mikäli arvo muuttuu, invalidoidaan attribuutti ja välitetään invalidoitumistieto eteenpäin.

4. Ainoastaan Ca//-käskyllä tapahtuva laskenta, invalidoituminen täysin estetty. Tämä vaihtoehto toteuttaa tavanomaisen metodin käsitteen. Uusi arvo lasketaan aina ja vain silloin kun attribuuttia kutsutaan laskentasääntökielen Ca//-funktion avulla.

Kutsu laskee ja palauttaa attribuutin arvon, eli käytännössä suorittaa kutsuttavan funktion koodin. Tällaisia laskentasääntöjä käyttäviä attribuutteja ei koskaan invalidoida, koska ei ole mielekästä tarkkailla potentiaalisia funktioiden paluuarvojen muutoksia.

2.3 Sovelluskehitinominaisuudet

2.3.1 Yleistä

Sovelluskehittimille asetetaan nykypäivänä monia vaatimuksia. Kaupallisessa tuotteessa tärkeää on järjestelmän helppokäyttöisyys. Ohjekirjojen ja tietokonepohjaisten opasteiden tulee olla riitävän kattavia, helposti ymmärrettäviä ja houkuttelevasti toteutettuja, jotta ohjelmistotalo ottaisi uuden kehittimen käyttöönsä.

Sovelluskehittimellä tehdyiltä sovelluksilta odotetaan usein vielä enemmän kuin itse sovelluskehittimeltä. Sovellusten toimintavarmuus on asiakkaalle usein itsestäänselvyys. Toteutuksen tehokkuus tulee esille viimeistään muutaman kuukauden

käytön jälkeen. Sovelluksen käyttöikää lisäävät huomattavasti helppo ylläpidettävyys ja laajennettavuus. Sovelluskehittimen lopullinen menestys riippuu kuitenkin sen ilmaisuvoimasta, siitä minkälaisia sovelluksia sillä voidaan rakentaa ja mitkä asiat ovat mahdottomia.

2.3.2 Käyttöliittymä

Järjestelmän oman käyttöliittymän oli oltava graafinen. Käyttöliittymä oli toteutettava englanninkielisenä siten, että siitä voitaisiin tarvittaessa tehdä erilaisia kieliversioita.

Tuotteistetun järjestelmän tulisi sisältää myös kattavat englanninkieliset suoraopasteet.

Moniperinnän salliva luokkahierarkia oli voitava visualisoida käyttäjälle suunnattuna verkkona sopivan algoritmin mukaisesti piirrettynä. Yksittäisen luokan tietoja oli voitava tarkastella ja muuttaa tätä tarkoitusta varten rakennetuilla lomakkeilla.

Luokkakohtaisilta lomakkeilta oli pystyttävä helposti siirtymään ko. luokan instansseihin. Instanssin tiedot oli näytettävä vastaavantyyppisillä lomakkeilla.

Järjestelmän oli kyettävä visualisoimaan graafisesti instanssien välisiä linkkejä ja niiden avulla muodostettuja hierarkioita tai muita verkkoja. Graafien solmuina olevien instanssien kuvakkeiden avulla oli päästävä tarkastelemaan ko. instanssin sisältöä.

Kaikkia instansseja oli myös voitava tutkia taulukkomuotoisina esitystapoina, joissa jokaisella rivillä on yksi instanssin tietoalkio sekä sen arvo. Lukulista-tyyppisen arvon

yksittäiset alkiot oli näytettävä peräkkäisissä sarakkeissa.

Kaikkien näkymien oli päivityttävä automaattisesti mallin muuttuessa. Johdettujen attribuuttien invalidoituessa oli uudet arvot laskettava ja näytettävä avoinna olevissa näkymissä. Luokkahierarkiassa tapahtuvien muutosten oli päivityttävä heti avoinna olevaan luokkahierarkiaikkunaan.

2.3.3 Taulukkonäkymät

Järjestelmään oli rakennettava mekanismi, jonka avulla mielivaltaisia mallissa olevia tietoja voitiin näyttää taulukkomuotoisten raporttien soluissa. Yhteen taulukko- näkymään oli voitava kerätä tietoja useista eri olioinstansseista. Kaikkia näkymässä esitettäviä ei-laskettuja tietoalkioiden arvoja oli voitava muuttaa kirjoittamalla päälle uusi luku. Uuden arvon oli välittömästi päivityttävä malliin.

Taulukkonäkymien välille oli voitava määritellä siirtymiä siten, että käyttäjä voi nappia painamalla avata uuden näkymän ja sulkea vanhan. Näkymien oli myös sisällettävä mekanismit valintalistojen esittämiseksi käyttäjälle näkymässä näytettävien tietojen muuttamiseksi.

Taulukkonäkymien ulkoasun määrittelyjen tuli olla erittäin monipuolisia. Jokaiselle solulle oli voitava valita omat värit, kirjasinlajit ja -koot, reunukset ja taustakuviot.

Näkymiin oli myös voitava sijoittaa yritysgrafiikassa yleisiä pylväs-, viiva- ja piirakka- diagrammeja otsikkoineen. Näkymien graafisen ulkoasun esittäminen voitiin toteuttaa

muiden kaupallisten ohjelmistojen avulla, mikäli integrointi tuotteiden välille oli mahdollista rakentaa riittävän monipuoliseksi ja tehokkaaksi. Näkymien välisten siirtymien ja valintalistojen oli oltava käytössä myös ulkoisista sovelluksista.

Ulkoasultaan viimeisteltyjen näkymien, niiden välisten siirtymien ja valintalistojen avulla oli voitava rakentaa 'johtajatason' raportointisovelluksia. Virhetilanteiden käsittely tuli toteuttaa niin, että loppukäyttäjä vakuuttuu järjestelmän toiminnasta ja tietojen oikeellisuudesta.

2.3.4 Ylläpidettävyys

Järjestelmän avulla rakennettujen sovellusten tuli olla mahdollisimman helposti ylläpidettäviä ja laajennettavia. Tähän oli pyrittävä kaikilla mahdollisilla keinoilla.

Ensisijaisesti tuli kaikkiin sovelluskehitinominaisuuksiin etsiä deklaratiivista toteutus­

tapaa. Sovelluskohtaisen ohjelmakoodin määrä voidaan minimoida kuvaamalla halutut rakenteet ja toiminta. Deklaratiivisten ominaisuuksien tuli kattaa niin suuri osa tarvittavista toiminnoista, että sovellusten rakentaminen olisi mielekästä.

Kaikkien oliomallinnuksen toimintojen oli oltava mahdollisia myös valmiissa sovel­

luksessa. Sovelluksen sisältämien instanssien oli ajonaikaisesti muututtava luokkiin ja luokkahierarkiaan tehtyjen muutosten mukaisesti. Oliomallinnus nähtiin jatkuvana prosessina, jossa käsitemalli muuttuu jatkuvasti uusien vaatimusten ja tarkkuustasojen mukaisesti.

Järjestelmän tuli auttaa käyttäjää rakennetun sovelluksen dokumentoinnissa. Luokkiin ja attribuutteihin oli voitava liittää kuvaus. Rakennetusta sovelluksesta oli voitava luoda automaattisesti raportteja, jotka mahdollisimman pitkälle kattaisivat tarvittavat j ärj estelmädokumentit.

2.3.5 Sovellusaluekohtaiset vaatimukset

Tässä työssä rakennattava järjestelmä oli tarkoitettu yrityksissä tarvittavien suunnittelujärjestelmien tekemiseen. Vaikka strateginen suunnittelu olikin alusta asti ollut etusijalla, oli suunnittelujärjestelmiin havaittu sisältyvän hyvinkin erilaisia tarpeita.

Kilpailijaseuranta, ympäristövaikutusten arviointi, laatujohtaminen, johdon raportointi, kustannuslaskenta ja budjetointi ovat kaikki alueita, joiden tarpeisiin voidaan rakentaa suunnittelujärjestelmiä.

Sovellusalueiden perusteellinen esittely rajattiin tämän työn ulkopuolelle. Tässä kappaleessa annetaan lukijalle viitteitä muutamiin teoksiin, joissa esitetyjä ajatuksia on huomioitu järjestelmän suunnittelussa ja asiakaskohtaisten sovellusten toteutuksessa.

Strateginen suunnittelu

Richard G. Hamermesh jakaa kirjassaan Strategic Management [Hame90] strategisen suunnittelun menetelmät tai tyylit kolmeen ryhmään: reagoivaan, intuitiiviseen ja

systemaattiseen suunnitteluun. Tietokoneavusteinen strateginen suunnittelu on yleensä systemaattisen suunnitteluprosessin tukemista.

Gerry Johnson ja Kevan Scholes ovat esittäneet kattavan rungon strategisen suunnittelun prosessille kirjassaan Exploring Corporate Strategy [JoSc88]. Strateginen johtaminen voidaan kirjan mukaan jakaa nykytilanteen analysointiin, strategisten toimintavaihtoehtojen muodostamiseen ja valittujen vaihtoehtojen toteuttamiseen organisaatiotasolla.

Michael E. Porter on esittänyt muutamia strategisessa suunnittelussa yleisesti käytettäviä malleja kirjassaan Competitive Advantage, Creating and Sustaining Superior Performance [Port85], Toimialan houkuttelevuus määritellään ostajien, raaka- ainetoimittajien, korvaavien tuotteiden, uusien tulokkaiden ja toimialan sisäisen kilpailun perusteella. Yleismaailmallisina strategioina esitetään vaihtoehdot kilpailuedulle (alhainen hinta tai erikoistuminen) ja kilpailukohteelle (laajat tai suppeat markkinat). Samassa kirjassa käydään myös läpi yleisen arvoketjun periaate, jota voidaan pitää runkona materiaalivirtojen laskennassa.

Stratex-järjestelmän kehitykseen osallistuneet Auli Kumpulainen, Martti Paajanen ja Ilkka Tuomi ovat käsitelleet strategisen suunnittelun asettamia vaatimuksia tietämyspohjaisille suunnitteluvälineille artikkeleissaan STRATEX: Toiminnallinen kuvaus [KuPa89], A Knowledge-Based Planning Tool for Strategic Management [Kump90] ja Adding Value to the Strategy Process Using Object-Oriented Modeling and Software Support [PaTu92]. Erityisesti korostetaan reaalimaailmassa esiintyviä riippuvuuksia ja niiden toteuttamista olioiden välisinä linkkeinä. Luokkahierarkia ja sen avulla muodostettava käsitemalli nähdään ratkaisuna asiakaskohtaisten suunnittelu- mallien toteutukselle.

Outokumpu Metals & Resources ryhmän suunnittelutarpeita ovat kuvanneet Pentti Niskanen ja Martti Paajanen artikkelissaan Multinational Mining Company Simulation [NiPa93]. Rakennettu suunnittelumalli sisältää yli tuhat toisistaan laskennallisesti riippuvaa oliota. Tärkeäksi toiminnoksi koettiin simulointimahdollisuuksien tehokas toteuttaminen. Strategisia päätöksiä varten voitiin esitetyn mallin avulla laskea useita vaihtoehtoisia tulevaisuuden skenaarioita.

Suuryrityksen rahoituksen perusteita ovat käsitelleet Richard A. Brealey ja Stewart C.

Myers kirjassaan Principles of Corporate Finance [BrMy91]. Erityisesti kirjassa käydään läpi nykyarvolaskentaa, riskienhallintaa, budjetointia, rahoitusvaihtoehtoja, osinkopolitiikkaa ja pitkän tähtäimen rahoitussuunnittelua.

2.4 Toteutuksen tehokkuus ja käyttöympäristö

Yleisimpien mallinnusympäristön perusoperaatioiden oli tapahduttava interaktiivisesti alle viidessä sekunnissa. Käsitemallin muutokset, erityisesti luokkahierarkian ja luokkien rakenteiden muutokset, oli optimoitava niin nopeiksi, että käyttäjä pystyy todella kokeilemaan rakenteellisten muutosten vaikutuksia.

Järjestelmän oli pystytävä käsittelemään vähintään tuhannen perinteisen taulukko- laskentalomakkeen tietomääriä ja laskennallisia riippuvuuksia. Tämänkokoisen mallin muistiin lataamiselle ja kovalevylle tallettamiselle asetetaan aikarajaksi noin yksi tunti.

Järjestelmä oli rakennettava graafiseen Microsoft Windows -käyttöjäijestelmään.

Helppokäyttöisyyden oli oltava käyttäjälle tuttujen yleissovellusten tasolla, tosin lopulliseen tuotteistukseen ei vielä tässä vaiheessa panostettu. Lopullisen tuotteistuksen yhteydessä järjestelmään on rakennettava kontekstiriippuvat opasteet (context-sensitive help), joiden tulee kattaa ainakin kaikki järjestelmän lomakkeet sekä yleisesti tehtävien toimintojen selitykset.

Suunnittelu- ja analysointikäytössä laitteiston minimivaatimuksena pidettiin tehokasta henkilökohtaista mikrotietokonelaitteistoa. Käytännössä keskusmuistia oli oltava vähintään 8 megatavua, suorittimena intel 486dx 33Mhz tai tehokkaampi ja näyttönä super-vga tasoa vastaava 800*600 resoluutioinen värinäyttö.

3 STRATEX-TOTEUTUS JA SEN ONGELMAT

3.1 Stratex-järjestelmän kuvaus

3.1.1 Käyttötarkoitus

Stratex oli työkalu strategisen yrityssuunnitteluprosessin tukemiseen [KuPa89].

Lähtökohtana oli yrityssuunnittelussa tarvittavan tiedon ja sen sisältämien riippuvuuksien kuvaaminen niin, että tilannearvioissa ja toimenpidevaihtoehtojen arvioinnissa voitiin hallita sekä yksityiskohtatason tietoa että vaikutuksia kokonaisuuteen. Yrityssuunnittelussa tarvittavan tietämyksen järjestämisellä helpotettiin monimutkaisen suunnitteluympäristön hallintaa ja mahdollistettiin päähuomion kiinnittäminen tiedon hyödyntämiseen ja innovointiin.

Stratex tarjosi apuvälineet yritystä ja sen toimintaa kuvaavien tietokokonaisuuksien ja niiden keskinäisten riippuvuuksien kuvaamiseksi. Kunkin liiketoiminnan yksikön osalta koottiin siihen vaikuttavat menestystekijät niiden eri ajanhetkiä kuvaavine arvoineen.

Näille liiketoiminnan tilaa kuvaaville mittareille voitiin määrittää lukuarvojen lisäksi erilaisia laadullisia arvoja asteikkoineen. Yksiköiden keskinäisiä suhteita voitiin kuvata riipuvuuksilla, ja lisäksi voitiin järjestelmän sisältämän laskentasääntökielen avulla toteuttaa tietojen yhdistelyä ja konsolidointia tasojen välillä.

3.1.2 Arkkitehtuuri

Yrityksen omassa yrityssuunnittelussa käytettävä tietämys koottiin malliin, jossa kuvattiin sekä tietämyksen tyypittämisessä ja ryhmittelemisessä tarvittavat tiedot että tietämykseen liittyvä yksityiskohtainen datatieto, esimerkiksi mallin taulukoiden sisältö.

Mallin avulla rakennettiin myös näkymiä, joiden avulla rakennetta ja tietoja voitiin tarkastella erilaisista näkökulmista.

Asiakaskohtainen malli rakennettiin Stratex-järjestelmän perustana olevan työkalukerroksen sisältämien modulien avulla. Työkalukerros tarjosi tietämyksen esittämisen ja hallinnan palvelut sekä käyttöliittymän toiminnot. Työkalukerroksen modulit oli rakennettu Lucid CommonLisp -ohjelmointikielellä käyttäen hyväksi sen sisältämiä CLOS-oliolaajennusta ja Window Toolkit käyttöliittymäkirjastoa [Luci92].

Tarvittava ikkunointijärjestelmä oli X Window System, käyttöjärjestelmävaihtoehtoja olivat UNIX-murteet SunOS ja AIX. Stratex-ohjelmiston ajonaikainen arkkitehtuuri on esitetty kuvassa 5. Kaikkien komponenttien tuli olla ladattuna työaseman muistissa.

rakennettu sovellus Asiakaskohtainen malli

r--- \ Stratex -työkalukerros (mm. TOP) Lucid CommonUsp & Window Toolki

3

c

J

C

^J

Stratex -työkalukerros ohjelmointikieli ikkunointijärjestelmä käyttöjärjestelmä Kuva 5 Stratex j ärj estelmän aj onaikainen arkkitehtuuri 3.1.3 Tyyppisuuntautunut ohjelmointi

Stratex-järjestelmä oli rakennettu tyyppiorientoituneen TOP-ytimen päälle. Tyyppi- suuntautunut olio-ohjelmointi (type-oriented programming) oli J. T. Bergqvistin esittämä lähestymistapa tietämyspohjaisten sovellusten rakentamiseksi [Berg87].

Perusajatuksena oli kahden rinnakkaisen hierarkian avulla kuvata reaalimaailmaa ja sen käyttäytymistä. Kuvassa 6 on esimerkki TOP-j ärj estelmän avulla tehdystä luokka- hierarkiasta. Sovelluksen rakentaja loi uusia luokkia Stratex-Element-luokan alaluokiksi. Luokkien avulla toteutettiin reaalimaailman rakenteen kuvaus. Attribuutit periytyivät luokkahierarkiassa normaalien periytymissääntöjen mukaisesti. Sovelluksen varsinaiset tiedot tallettuivat luokkahierarkian luokista luotuihin instansseihin.

%%BASIC-ELEMENT%0/

TATEX-ELEMEN /М

<¿/Bl

vei

ATRIX BUSINESS-UNI CUSTOMER RESOURCE

CHILD-COMPANY PARENT-COMPANY

/ACTIVE-ELEMENT-CLASS

‘GENERIC-UIM-CLASS^-MENU ЛЛ/INDOW

Kuva 6 Esimerkki TOP-järjestelmän luokkahierarkiasta

TOP-j ärj estelmän toinen, luokkahierarkialle rinnakkainen tyyppihierarkia on esitetty kuvassa 7. Tyyppihierarkia mahdollisti uusien tyyppien luomisen olemassa olevien tyyppien pohjalta. Tyypit määrittelivät sovelluksen komponenttien käyttäytymisen.

Tyyppejä voitiin liittää luokkiin, instanseihin ja tietoalkioihin. Yhteen komponenttiin voitiin liittää useita tyyppejä. Luokkiin liitettyjen tyyppien olisi pitänyt periytyä

edelleen instansseille ja alaluokille. Tietämystyypeille määriteltiin aspekteja, jotka vastasivat olio-ohjelmoinnin instanssien attribuutteja. Tyyppejä voitiin instantioida, jolloin aspekteille annettiin perustyyppimäärittelystä poikkeavia arvoja.

Ne tietämystyypit, joita käytettiin määrittelemään tietämyspalasen rakennetta, toimivat kuten normaalit ohjelmointikielistä tutut tyypit. Kun tietämyspalaseen liitettiin kokonaislukutyyppi, voitiin tietämyspalasen arvoksi tallettaa kokonaisluku. Kun tietämyspalaselle lähetettiin viesti tulosta, käsitteli kokonaislukutyyppi viestin ja tulosti ruudulle tietämyspalasen arvona olevan kokonaisluvun.

Tietämyspalasiin voitiin liittää myös ns. aktiivisia tietämystyyppejä, esimerkiksi päättelysääntöjä. Tällöin tyypit vaikuttivat tietämyspalasten käyttäytymiseen siten, että ne vastaanottivat tietämyspalasille lähetettyjä viestejä ja käyttäytyivät omien ns.

tulkintojensa mukaisesti. Uusia tulkintoja kirjoitettiin aspekteihin liitettävänä Lisp- koodina. Tietämyspalasen vastaanotettua aktiivisen tietämystyypin ymmärtämän viestin, suoritettiin tietämystyypin mukainen tulkinta. Päättelysääntö-tietämystyypillä oli esimerkiksi ainakin yksi aspekti, varsinainen päättelysääntö.

ITEM-TYPE

% % B A SIC - TY P E % % \

OP-STRING OP-NUMBER-

OP-LIS1--- TIME-SERIES-TYP

NUMBERLIST

OP-BOOLEAN

QUALITATIVELY

■ACTIVE-SHEET-TYPE

ELEMENT-TYPE \

BENERIC-UIM-ELEMENT-TYP^—MENU-TYPE

ZAC

ЛЛ/INDOW-TYPE 'APPLICATION-DEFINITION-TYPE

/lEW-TYPE 3ALC-RULE-TYPE

Kuva 7 Esimerkki TOP-j ärj estelmän tyyppihierarkiasta

Tyyppisuuntautunut ohjelmointi ei sisältänyt käsitettä metodi. Tietämyspalasten rakenteeseen ei kuulunut funktioita, joita olisi voitu kutsua ulkoapäin, vaan kommuni­

kointi hoidettiin tietämyspalasten toisilleen lähettämien viestien avulla.

Tietämystyyppien sisältämiä tulkintoja erilaisille viesteille voidaankin pitää oliomallin metodien vietinvälitykseen perustuvina implementaatioina.

3.2 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.