hyväksymispäivä arvosana arvostelija Logiikkakielen upottaminen olio-ohjelmiin Pietu Pohjalainen Helsinki 18. huhtikuuta 2004 Seminaarityö HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
i Logiikkakielen upottaminen olio-ohjelmiin Pietu Pohjalainen Seminaarityö Tietojenkäsittelytieteen laitos Helsingin yliopisto 18. huhtikuuta 2004, 9 sivua Perinteisesti logiikkakieliä ja skriptikieliä käytetään erilaisten asioiden saavuttamiseen: logiikkakielellä voidaan ilmaista monimutkaisia nimettyjen symbolien välisiä suhteita, ja ohjelmoija haluaa keskittyä ohjelman kontrollin kulkuun mahdollisimman vähän. Skriptikielissä puolestaan ohjelman kontrollin ilmaiseminen on taas vahvalla sijalla siinä mielessä, että skriptikielellä kirjoitettu ohjelma usein toimii muiden ohjelmiston komponenttien välisenä välittäjänä, kontrollin pitäjänä. Tässä tutkielmassa esitetään tapa upottaa logiikkakielellä kirjoitettuja skriptejä oliokieleen. Tällä menettelyllä tavoitellaan mahdollisuutta ilmaista logiikkakielille ominaisilla tavoilla asioiden välisiä yhteyksiä oliokielisessä ohjelmistossa. Aiheluokat(Computing Reviews 1998): Avainsanat: logiikkakielet, skriptikielet
1 Johdanto 1 Ohjelmointikielten kategorisointeja, paradigmajakoja kirjattaessa logiikkaohjelmointi ja imperatiivinen ohjelmointi nähdään usein erillisiksi, luonteeltaan toisistaan kaukana oleviksi ohjelmointitavoiksi. Logiikkakielet mielletään usein olevan luonteeltaan deklaratiivisia: ohjelmoijaa ei kiinnosta miten haluttu tulos saadaan, kunhan halutun tuloksen määritteleminen on intuitiivista ja nopeaa. Toisaalta, perinteisen paradigmajaon pohjalta logiikkakielet nähdään usein erillisinä saarekkeina, jonne tavallisella ohjelmoijalla ei juurikaan ole asiaa. Kuitenkin, monia imperatiivisessa ohjelmoinnissa esiintyvien monimutkaisia kontrollirakenteita vaativien ongelmien toteuttaminen onnistuisi varsin suoraviivaisesti jollakin logiikkakielellä. Siinä missä tietokantojen kyselykielet, kuten SQL, ovat nykyisin useinkin osana laajempia projekteja, on logiikkakielten, kuten Prolog toteutusten käyttäminen harvinaisempaa. Tässä tutkielmassa esitetään yksinkertainen propositiologiikan vahvuinen logiikkakieli, joka voidaan upottaa komponenttina osaksi laajempaa olio-ohjelmaa. Sopivia adapteriluokkia käyttäen kehitetty logiikkakieli ohjataan käyttämään olioohjelman sisäiseen oliomalliin kuuluvia olioita, ja näin saavutetaan perinteisiä logiikkakieliä tiukempi sidonta näiden kahden paradigman välille. 2 Logiikkaohjelmoinnin upottaminen oliokieleen Kuvassa 1 esitetään prosessi, jolla yleistä logiikkakomponenttia voidaan hyödyntää oliojärjestelmässä. Kuvassa vasemmalla esitetään yleinen tapa järjestelmän hyödyntämiseen. Kuvassa oikealla esitetään soveltaminen erääseen ongelma-alueeseen, luokkahierarkian analyysiin. Ongelma-alueen mallinnuksella tarkoitetaan vaatimusanalyysin vaihetta, jossa käsiteltävä ongelma pilkotaan osiin. Kuvan esimerkissä käsiteltävänä ongelmana on oliokielessä esiintyvien luokka-hierarkioiden tutkiminen:
2 Yleinen prosessi Ongelma alueen mallinnus Luokkahierarkian tutkiminen Esimerkki Predikattien toteuttaminen CLASS(x), EXTENDS(x, y) Sitominen päättelykoneistoon CLASS > Class EXTENDS > Extends Järjestelmä käytettävissä Järjestelmä käytettävissä Kuva 1: Yleinen kehitysprosessi ja sen soveltaminen kielessä on mahdollisuus määritellä luokkia sekä näiden välisiä periytymissuhteita, ja lisäksi tiedetään, että toteutettavassa ohjelmistossa joudutaan käsittelemään näihin asioihin liittyviä kysymyksiä. Predikaattien toteuttaminen tarkoittaa edellisessä vaiheessa esilletulleiden primitiivipredikaattien toteuttaminen tarkoittaa päättelysääntöjen kirjoittamista käytetyllä oliokielellä. Kuvan esimerkissä oleva predikaatti CLASS(x) toteutetaan antamalla 1. päätössääntö siitä, onko parametrina annettu literaali luokka vai ei (totuussääntö) 2. luettelointisääntö siitä, mitkä oliot ovat luokkia Näitä kahta sääntöä soveltamalla päättelykoneisto yrittää ratkaista annettavat logiikkakaava.
3 Sitominen päättelykoneistoon tarkoittaa predikaattien ja niiltä vaadittujen päättelysääntöjen toteutuksen sitomista toisiinsa. Esimerkissä sidotaan predikaatin CLASS toteutus oliokielen luokkaan Class ja predikaatin EX- TENDS toteutus oliokielen luokkaan Extends. Kehitettäessä ongelma-aluekohtaisia predikaatteja pyritään alue mallintamaan pienimpiin käsiteltäviin yksiköihin. Tämä vaatii luonnollisestikin tietämystä käsiteltävästä alueesta, mutta tätä vaatimusta ei voi pitää huonona asiana, sillä jos käyttäjältä toteutusvaiheessa puuttuu riittävä näkemys käsiteltävästä ongelmaalueesta, ollaan ongelmissa käytetystä ohjelmointitekniikasta riippumatta. 2.1 ALF -järjestelmä ALF -järjestelmässä [Mel88] päämääränä on ollut integroida Smalltalk- ja Prolog -kielet luonnollisella tavalla yhteenkäytettäviksi. 1. sekä logiikkakielen että oliokielen puolella käsitellään samaa dataa 2. kaikki käytetyt rakenteet ovat olioita 3. oliokielen luokkahierarkia toimii yhteen käytetyn logiikkajärjestelmän kanssa Näistä periaatteista nähdään, että järjestelmässä lähestymistapa on samankaltainen kuin tässä työssä esitettävässä. Oliokieltä käytetään ohjelmiston pääosan laatimiseen, ja logiikkalaajennokset suunnitellaan oliojärjestelmän tarpeita ajatellen. ALF -järjestelmässä on kuitenkin eräs vakava rajoite olio- ja logiikkakielten yhdistämistä ajatellen: kaikkien käytettävien predikaattien tulee olla luokan Predicate aliluokkia. Tämän seurauksena kaikki käytettävät luokat on alusta alkaen sovitettava ALF:ia ajatellen; toisin sanoen, päättelykoneiston lisääminen olemassaolevaan järjestelmään vaatii suuria muutoksia olemassaolevaan luokkahierarkiaan.
4 2.2 Emoole Emoole, EMbeddable Object-Oriented Logic Engine on toteuttamani edellisen luvun periaatteita noudattava logiikkakielen toteutusjärjestelmä Java-ympäristöön. Järjestelmän peruskomponenttina on eteenpäinketjutusta käyttävä päättelykone, joka voidaan konfiguroida eri ongelma-alueille antamalla aluekohtaiset predikaatit ja niihin liittyvät päättelyluokat. Tällä jaolla voidaan järjestelmää käyttää komponentin kaltaisesti siten, että komponenttia kullakin ongelma-alueella käytettäessä riittää aluekohtaisten päättelysääntöjen kirjoittaminen - itse päättelykoneisto voidaan uudelleenkäyttää päättelyn alueesta riippumatta. 2.2.1 Järjestelmän rakenne Toteutettu logiikkakone on pinoa muistirakenteenaan käyttävä tulkki, jolla on neljä primitiivikäskyä: 1. Lue arvo pinon huipulta 2. Korvaa muuttuja arvolla 3. Testaa predikaatin totuus 4. Kirjoita pinon huipulle Muita järjestelmän komponentteja ovat JavaCC-jäsentäjägeneraattorilla 1 toteutettu kyselykielen jäsentäjä ja alakohtaisten päättelysääntöjen sidontaan tarkoitettu mediaattori [GHJV95, s. 273-282] -suunnittelumallin mukainen välitysmoduli. Järjestelmän korkean tason rakenne esitetään esitetään kuvassa 2. 1 http://javacc.dev.java.net
5 Asiakas ohjelma Päättely koneisto sidonta Aluekohtaiset päättelysäännöt #1 Aluekohtaiset päättelysäännöt #2 Kuva 2: Järjestelmän korkean tason rakenne 2.2.2 Käytettävä kieli Järjestelmässä toteutettuja predikaatteja voidaan tällä hetkellä yhdistellä AND ja NOT -konnektiiveilla. Lisäksi predikaatit voivat olla vain yksi- tai kaksipaikkaisia. Näillä rajoituksillakin kieli on jo varsin käyttökelpoinen, sillä käytössä oleva konnektiivipari on täydellinen, ts. kaikki propositiologiikassa ilmaistavissa olevat kaavat ovat käännettävissä vain näitä konnektiiveja käyttäviksi kaavoiksi. Lisäksi, mikä tahansa n-paikkainen predikaatti on käännettävissä sopivia välipredikaatteja käyttäen joukoksi yksi- ja kaksipaikkaisia predikaatteja. Käytettävän kielen kielioppi voidaan esittää seuraavasti: CONSTRAINT ::= { NOT? PREDICATE}* PREDICATE ::= IDENTIFIER (VAR_OR_LITERAL {, VAR_OR_LITERAL}?) VAR_OR_LITERAL ::= IDENTIFIER.* IDENTIFIER ::= [A-Z][A-Z0-9]* Tässä esitysmuodossa kysymysmerkki ja tähti tarkoittavat, kuten normaalisti esiintymiskertojen lukumääriä 0 1 ja 0 n. Hakasulkeita käytetään kuten tavallisesti säännöllisten lausekkeiden yhteydessä, tarkoittaen arvoväliä. Kaarisulkeet tarkoittavat ryhmittelyä. Nyt, jos oletetaan predikaatit CLASS(x), EXTENDS(x, y) ja EQUALS(x, y), voidaan tällä kielellä tehdä kysely kaikkien luokan java.lang.object aliluokkien lis-
6 taamiseksi: CLASS(x) AND EQUALS(x, java.lang.object ) AND CLASS(y) AND EXTENDS(y, x) Nyt, uusien samaa ongelmakenttää koskevien predikaattien toteuttaminen on varsin suoraviivaista: helposti voidaan laajentaa esimerkkiä käsittelemään rajapintoja, luokkien jäsenmuuttujia ja -metodeja ja niin edelleen. 2.2.3 Päättelyprosessi Itse päättelyprosessi on toteutettu suoraviivaisena silmukkana, joka käyttää pinoa välitulosten ylläpitämiseen. Kuvassa 3 esitetään päättelyn eteneminen annetun yksinkertaisen kyselyn yhteydessä. Jäsentäminen CLASS(x) AND EQUALS(x, Object ) Tulos x = Object Logiikkakone CLASS( Object ) AND EQUALS( Object, Object ) OR CLASS( String ) AND EQUALS( String, Object ) Kuva 3: Päättelyprosessi yksinkertaisella kyselyllä Yleisesti esitettynä päättely kulkee seuraavasti: 1. Jäsentäjä käsittelee annetun syötteen ja muodostaa listan, joka sisältää kaikki kyselyyn kuuluvat predikaatit ja niiden argumentit. Tämä lista asetetaan
7 työskentelypinon huipulle. 2. Logiikkakone lukee kyselyn pinon huipulta, vaihtaa muuttujia predikaattien luettelointisääntöä käyttäen literaaleiksi, ja kirjoittaa pinoon kaikki ne kyselyt, jotka ovat vielä tässä vaiheessa tosia. 3. Tulosjoukkoon päätyvät ne kyselyt, joiden kaikki predikaatit ovat muuttujien muuntamisen jälkeen tosia. Suurin taika tehdään siis predikaattien toteutuksessa, eli predikaatin luettelointisäännössä ja totuussäännössä. Kuvan 3 suoritusta voidaan seurata myös tarkkailemalla tehtyjä metodikutsuja sekä pinon tilaa kussakin vaiheessa. Tällöin suoritusprosessi näyttää seuraavalta: Pino (1): {CLASS(x) AND EQUALS(x, Object )} Aluksi pinossa on syötteenä annettu kysely. Ensimmäinen käsiteltävä muuttuja on x, jolloin predikaatin CLASS luettelointisäännöltä kysytään kaikki saatavilla olevat luokat, joita ovat Object ja String. Kullekin mahdolliselle vaihtoehdolle jokainen muuttujan x ilmentymä uudelleenkirjoitetaan, ja tulokset kirjoitetaan pinoon. Kukin pinossa oleva kysely siis tarkoittaa TAI-konnektiivilla yhdistettyä tulosjoukon mahdollisuutta. Pinon tila: Pino (2): {CLASS( Object ) AND EQUALS( Object, Object )}, {CLASS( String ) AND EQUALS( String, Object )} Nyt, prosessi alkaa alusta. Logiikkakone lukee pinon päältä ensimmäisen kyselyn. Koska kyselyssä ei ole enää muuttujia, kutsutaan molempien kyselyssä esiintyvien predikaattien totuussääntöä. Nämä molemmat palauttavat toden, joten tämä x:n arvo päätyy tulosjoukkoon. Pinon tila nyt: Pino (1): {CLASS( String ) AND EQUALS( String, Object )} Prosessi aloitetaan taas alusta. Ensimmäinen predikaatti on totta, mutta jälkimmäinen ei ole, joten tämä vaihtoehto (x = String ) hylätään.
8 2.2.4 Vertailu muihin järjestelmiin Luvun 2.2.2 kaikki annetun luokan aliluokkien toiminnallisuuden toteuttaminen Javalla vaatii tyylistä riippuen noin 100 riviä ohjelmakoodia, joten annettu esimerkki neljän rivin pituisena on varmastikin nopeampi kirjoittaa ja hyvinkin myös helpompi ymmärtää. Yleisistä päättelyalgoritmeja Davis ja Putnam [DP60] esittävät algoritmin konjunktiivisessa normaalimuodossa olevien predikaattilogiikan kaavojen totuuden ratkaisemiseen. Robinson [Rob65] esittää pelkkään resoluutioperiaatteeseen perustuvan ratkaisumenetelmän. Tässä esityksessä käytetty ongelma-aluekohtaisten listaussääntöjen käyttäminen muistuttaa Bancilhonin [BMSU86] taikajoukkojen käyttämistä. Järjestelmän suorituskyvystä ei vielä tällä hetkellä ole riittävästi kokemuksia: toistaiseksi kaikki kokeillut ongelma-aluekohtaiset sovitukset ovat olleet tarpeeksi nopeita. 2.2.5 Jatkokehitys Vaikkakin yllä esitettyyn tarkoitukseen kehitetty järjestelmä on soveltuva, on siinä silti monia selviä kehitystä kaipaavia osa-alueita. Niitä ovat ainakin Tuki predikaattilogiikalle ja korkeampien kertaluokkien logiikoille. Vaikkakin käytettävän logiikkakielen rajaaminen propositiologiikan tasolle tekee mahdollisista kyselyistä hyvin yksinkertaisia ja helposti ymmärrettäviä, on kuitenkin selvänä vaarana, että nämä ovat liian yksinkertaisia. Tällöin järjestelmästä ei ole toivottua hyötyä käyttäjälleen Kyselyiden käsitteleminen olioina. Tällä hetkellä kyselyt ovat komponentin ulkoiselle tarkastelijalle olemassa vain tekstuaalisessa muodossa, joka kaavan ratkaisuprosessin aikana jäsennetään sisäiseen esitysmuotoon. Mahdollisuus kaavojen ohjelmalliseen käsittelyyn toisi edellä mainittua käytön
9 helppoutta järjestelmän soveltajalle. Käännetyt kyselyt. Tällä hetkellä logiikkakoneen toiminta on tulkkaavaa. Annetut kyselyt voitaisiin myös jäsennysvaiheessa kääntää suoritusympäristön ymmärtämäksi alemman tason kieleksi, toisin sanoen. Javan tavukoodiksi. Tällöin suoritusympäristön dynaaminen kääntäjä mahdollisesti pystyisi kääntämään suoritettavat kyselyt aina konekielelle saakka. Tällä menettelyllä saavutettaisiin potentiaalisesti kertaluokkaa olevia suorituskykyparannuksia. Kutakin jatkokehitysehdotusta tullaan järjestelmän tulevan elinkaaren aikana harkitsemaan vakavasti, mutta tällä hetkellä on liian aikaista järjestää näitä mihinkään tärkeysjärjestykseen. 3 Yhteenveto Tämän työn kantavana ajatuksena on ollut kehittää käytännön ohjelmistotyössä sovellettavissa olevia keino logiikkaohjelmoinnin ja olio-ohjelmoinnin yhdistämiseksi. Suurimpana hyötynä tällaisessa toiminnassa nähdään luettavuuden paraneminen. Wittgensteiniä lainaten: Mistä ylipäänsä voi puhua, sen voi sanoa selvästi; mistä ei voi puhua, siitä on vaiettava. Seminaarityössä esitetyllä propositiologiikan vahvuisella kielellä voidaan yksinkertaisella tavalla määritellä olioiden välisiä monimutkaisia suhteita, joiden hakemisen toteuttaminen perinteisellä imperatiivisella kielellä olisi vaivalloista ja virhealtista. Järjestelmän jatkokehitykseen on vielä syytä panostaa, sillä hyödyllisiä lisäominaisuuksia on näkyvissä jo pienelläkin lisävaivalla. On kuitenkin muistettava, että mahdollisten ylimääräisten toimintojen myötä järjestelmä muuttuu myös monimutkaisemmaksi ja siten vaikeammaksi ymmärtää. Tällöin vaarana on alkuperäisen idean: yksinkertaisen, skriptinomaisen logiikkaohjelmoinnin unohtuminen.
Lähteet 10 BMSU86 DP60 GHJV95 Mel88 Francois Bancilhon, David Maier, Yehoshua Sagiv, and Jeffrey D Ullman. Magic sets and other strange ways to implement logic programs (extended abstract). In Proceedings of the fifth ACM SIGACT- SIGMOD symposium on Principles of database systems, pages 1 15. ACM Press, 1986. Martin Davis and Hilary Putnam. A computing procedure for quantification theory. Journal of the ACM, 7(3):201 215, 1960. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York, NY, 1995. Fred Mellender. An integration of logic and object-oriented programming. ACM SIGPLAN Notices, 23(3):181 185, Oct 1988. Describes the ALF system. Rob65 J. A. Robinson. A machine-oriented logic based on the resolution principle. Journal of the ACM, 12(1):23 41, 1965.