Apua ja kättäpidempää digitalisoituvan maailman rakentajille.
Jospa vihdoinkin 1960-luvulta peräisin olevat ja peräkkäisohjelmien tekemiseen kehitetyt ohjelmointiparadigmat ja -käytännöt saisi korvattua uusilla, paremmin digitaalisen aikakauden älykkäiden, vuorovaikutteisten ja dynaamisten järjestelmien rakentamiseen sopivilla.
Oheislukemista englanniksi - Supplementary materials.
Ajattelumalli on tärkeämpi kuin työkalut.
Toki olemme rakentaneet työkalujen prototyyppejä ja demoja. Ilman niitä olisi ollut mahdoton vakuuttua, että esitetyt ideat toimivat myös käytännössä.
Suurin osa aktiopohjaisen ohjelmoinnin hyödyistä on mahdollista saada ilman työkalujakin. Olennaisempaa on ajattelumallin omaksuminen, sillä sitä pystyy hyödyntämään myös olemassa olevien työkalujen kanssa.
Aktiopohjaisen ohjelmoinnin tuoma lisäarvo on järjestelmän sisäisen vuorovaikutuksen hallinta. Vuorovaikutuksen mallintamisen ja analyysin periaatteet taas ovat paradigmariippumattomat ja käytetyistä välineistä ja ohjelmointikielistä johtuvat erot ovat pelkästään syntaktisia.
Aktiopohjainen ohjelmointi muuttaa lopulta kaiken, mutta ei tee sitä kertarysäyksellä.
Aktiopohjaisen ohjelmoinnin teoria on peräisin formaalista spesifioinnista ja verifoinnista, ja se jalostui käyttökelpoiseen muotoon mallipohjaisen testauksen yhteydessä. Niinpä sitä voi ensin käyttää vaikka testiautomaation rakentamiseen tai suunnittelun apuvälineenä, kun haluaa saada nopeasti tuntumaa aiheeseen ja abstraktin kokonaiskuvan järjestelmän toiminnasta.
Ajattelutavankin on mahdollista levitä organisaatiossa henkilö kerrallaan. Ensin yksi pioneeri käyttää sitä vaikeimpien haasteiden selättämiseen. Muut oppivat vähitellen ja omista lähtökohdistaan nähtyään käytännössä, miten temppu tehdään, ja kyseltyään ja kokeiltuaan itse lisää.
Aktiopohjainen ohjelmointi helpottaa rinnakkaisohjelmoinnin oppimista.
Rinnakkaisohjelmoinnin vaikeus ja virhealttius johtuu suurimmaksi osaksi nykyisin käytössä olevista välineistä. Tilaräjähdys eli äärimmäinen monimutkaisuus on vuorovaikutteisten järjestelmien luontainen ominaisuus. Nyt yleisesti käytössä olevilla välineillä järjestelmän toimintaa pitää kuvata auki kirjoitetussa muodossa, joka on kooltaan eksponentiaalinen luontevaan esitystapaan verrattuna.
Aktiopohjaisessa ohjelmoinnissa järjestelmä kuvataan hallittavan kokoisina osina ja vuorovaikutuksen mukana tuleva monimutkaisuus eli tilaräjähdys tulee vastaan vasta suoritusaikana. Lisäksi kääntäjät ja varusohjelmistot huolehtivat muistinhallinnan ja poissulkemisen kaltaisista toteutusyksityiskohdista.
Tutkimusjohtaja
Erityisasiantuntija
Asiantuntija
Asiantuntija
Kirjaa kirjoitamme GitHubissa osoitteessa https://github.com/apotr/Aktiopohjainen_ohjelmointi
Aktiopohjaisen ohjelmoinnin juuret ulottuvat 1980-luvun lopulle ja 1990-luvulle. Silloin vesiputousmallin kultakaudella formaali verifiointi ja spesifiointi tuntuivat lupaavilta ideoilta tehdä virheetömiä ohjelmia. Mutta vesiputousmallin korvasi iteratiiviset kehitysprosessit ja ohjelmistojen päivittäminen automatisoitiin. Näin kerralla valmista ajattelusta luovuttiin, löydetyt virheet vain korjataan ja käyttäjälle asennetaan uusi versio aina kun on tehty muutoksia.
Verifioinnin ja spesifioinnin yhteydessä kehitetty teoria sinänsä on kelvollinen. Toisin kuin ennen teoriaa käytetään nopeuttamaan ja helpottamaan kehitystyötä niin, että myös osaamistarve vähenee.
Aktio käsitteenä tarkoittaa atomista, jakamatonta ja yhtenä kokonaisuutena tehtävää asiaa. Kun aktioilla kuvataan toimintaa, keskeinen kysymys on, mitä voi tapahtua seuraavaksi.
Toinen keskeinen käsite on olio. Olioita käytetään tiedon esittämiseen ja välittämiseen aktioiden välillä. Ne ovat siis muuttujia. Järjestelmä huolehtii, että kaksi aktiota ei voi käyttää mitään oliota samaan aikaan. Näin yksi rinnakkaisohjelmoinnin hankalimmin hallittavista jutuista eli poissulkeminen ei enää ole suunnittelijan ja ohjelmoijan vastuulla.
Kolmas käsite on subjekti. Yksi tapa hahmottaa subjekteja on pitää niitä korkean tason algoritmeinä, joissa kerrotaan aktioiden toivottu suoritusjärjestys. Ne ikäänkuin rajaavat teoriassa mahdolliset tulevaisuudet käytännössä järkevään osajoukkoon.
Ohjelmistokehityksen toteutusvaiheet eli suunnittelu, toteutus ja testaus säilyvät, mutta niiden sisältö ja painotukset muuttuvat.
Suunnittelussa tuotetaan järjestelmän aktiopohjainen ja formaali toimintamalli. Koska malli on formaali, siitä voi hankkia objektiivista palautetta jo kauan sitten kehitetyillä keinoilla. Ja muutenkin monimutkaisia järjestelmiä kuvatessa täsmällinen esitysmuoto auttaa ymmärtämään, mitä kaikkea ylimääräistä suunnitelman mukainen järjestelmä voisikaan todellisuudessa tehdä.
Toteutus vaihe rajautuu pienempiin, aktion kokoisiin osiin ja sitä kautta suoraviivaistuu ja helpottuu. Kaikki vuorovaikutuksen eli osien yhteistoiminnan hallinnan toteutus saadaan suoraan suunnitteluvaiheessa tehdystä mallista, ja se vain linkitään yhteen aktioiden toteutusten kanssa.
Testauksen painopiste muuttuu järjestelmätason automaattisesta toiminnantestauksesta ei-toiminnalliseen ja tutkivaan testaukseen.