Käsitellään muutamia yleisimpiä tapoja visualisoida tietokone ja logiikka ohjelmia. Lähteenä on käytetty netistä löytyvää aineistoa, alan kirjallisuutta sekä eri ohjelmointiympäristöjä. Alkuun esitetään lyhyt katsaus ohjelmoinnin muinaishistoriaan. Sisällön kannalta on pakko käyttää kuvia, koska visualisoinnin sanallinen kuvaus on mahdotonta rajallisessa ajassa. Kuvat on sijoitettu linkeiksi, jotka avautuvat uuteen ikkunaan.

Lisäksi käsitellään UML kuvauskieltä hiukan tarkemmin. Esitetään myös muutamia tärkeimpiä UML menetelmiä. Tutkielman tarkoitus on antaa lukijalle alkutiedot erilaisista tavoista visualisoida ohjelmia, oppia mistä ja millaisia visualisointi työkaluja käyttää, sekä antaa valmiudet tietokone ohjelman luomiseen ja dokumentointiin käyttäen yleisiä visualisointi menetelmiä.

Sisällysluettelo

Ohjelmien visualisointi 1

Tiivistelmä 2

1. Johdanto 4

2.Historia 4

3.Vuokaaviot 5

4.Ohjelmakoodin visualisointi tekstieditoreissa 5

5.Yksinkertaisten ohjelmien visualisointi sovelluskehittimissä 5

6.Luokkien visualisointi ohjelmointi työkaluissa 6

7. J2ME ohjelmien visualisointi 6

8. CRC (Class-Responsibility-Collaboration) kortit 6

9. Ajettavien ohjelmien visualisointi 7

10.Cam ohjelmien visualisointi 7

11.Logiikkaohjelmien visualisointi 7

12.SQL Visualisointi 8

13.UML (Unified Modeling Language) 8

13.1.Mallinnus 8

13.2.UML Kaaviot 9

13.3. Käsitteistö 10

13.4.Muutamia esimerkkejä UML mallinnuksen käytöstä 10

13.4.1. Käyttötapaukset 10

13.4.2.Pakettikaaviot 11

13.4.3.Luokkakaaviot 11

13.4.4.Tilakaaviot 11

14.Esimerkki ohjelman kehityksestä 11

14.1.Käyttötapaus kaavio. 12

14.2.Luokkakaavio 12

14.3.Pakettikaavio 12

14.4.Käyttöliittymän piirtäminen 13

14.5.Koodin kirjoitus 13

14.6.Optimointi 13

15.Visualisointi menetelmien vertailu 13

16.Tulevaisuus 13

17.Lähdeluettelo : 14

17.1.1.Kirjat: 14

17.1.2.Lehdet : 15

17.1.3.Linkit : 15

17.1.4.Ohjelmat : 15

1. Johdanto

Ohjelmakokonaisuuden hahmottaminen on usein vaikeaa ja tilanteessa, jossa projektia joudutaan selittämään maallikoille tai uusille työntekijöille, tarvitaan keinoja, joilla asiat kerrotaan nopeasti.

Toinen tilanne, jossa kokonaisuus täytyy saada nopeasti esiin, on ohjelmiston suunnittelu tilanne.

Kolmas merkittävä tilanne on koulutus. Näistä tarpeista johtuen on kehitetty muutamia menetelmiä ohjelmien visualisoimiseen. Näihin tarkoituksiin on luotu muutamia helppokäyttöisiä menetelmiä.

2.Historia

Alkujaan ohjelmat kirjoitettiin konekielellä, joka ei ollut kovinkaan intuitiivista tai visuaalista. Sittemmin ohjelmoijien laiskuuden kasvaessa ja ohjelmoijien määrän kasvaessa otettiin käyttöön symbolinen konekieli, assembly. Kun ohjelmointi täten muuttui jokamiehen lajiksi, laiskuus kasvoi uskomattomiin mittoihin ja luotiin lisää monia ohjelmointia helpottavia asioita kuten käyttöjärjestelmä. Samalla luovuttiin symbolisen konekielen käytöstä ja siirryttiin korkean tason kieliin, jotka eivät ole sidoksissa yhteen prosessoriin. Näistä kielistä tunnetuin ja käytetyin lienee C, jolla kirjoitettiin UNIX käyttöjärjestelmä Bell Laboratories yhtiössä 1970 luvulla (Prata, 1995). C-kieltä voitaneen siis pitää ensimmäisenä merkittävänä ohjelmakoodin visualisoijana, joskin se joidenkin mielestä ei ole erityisen selkeä.

Selkeyden kasvattamisen tarvetta korjaamaan kehitettiin useita kieliä, joista tunnetuin lienee Microsoft-yhtiön Basic, helppokäyttöisin Smalltalk ja tehokkain C++, joka toi C-kieleen olio-ohjelmoinnin.

Alkujaan ohjelmien visualisointi hoidettiin piirtämällä taululle kuvia, käyttämällä pahvisia kortteja (CRC), joissa oli olion kuvaus, sekä tietenkin vuokaaviolla.

Kortteja on seurasi General Electricillä 1994 työskennelleen Jim Rumbaugh (Fowler & Kendal, 2002) kehittämä OMT mallinnuskieli.

Tästä olikin lyhyt matka UML kieleen, jonka kehityksestä ovat vastanneet alussa Ivar Jacobson, Jim Odelin ja Grady Booch.

3.Vuokaaviot

Yksinkertaisin tapa visualisoida muutamia lauseita on vuokaavio. Sitä voidaan käyttää opetuskäytössä, mutta suurempien kokonaisuuksien hallinta sen avulla on mahdotonta tai ainakin erittäin vaikeaa.

4.Ohjelmakoodin visualisointi tekstieditoreissa

Muinaiset ohjelmoijat kehittivät monia apuvälineitä tehdäkseen ohjelmoinnista helpompaa ja eliminoidakseen virheitä. Tunnetuimpia lienee UNIX-yhteisön käyttämä emacs. Nykyisin lähes jokainen tekstieditori kykenee värikoodaamaan koodin, joskin sisennys täytyy tehdä itsenäisesti.

5.Yksinkertaisten ohjelmien visualisointi sovelluskehittimissä

Microsoftin Alan Cooper teki 1987 ohjelmien visualisoinnin prototyyppi ohjelman nimeltä Ryby. Ohjelma yhdistettiin Q-basic kieleen ja syntyi Visual Basic 1. Aikanaan tätä pidettiin vallankumouksena ohjelmoinnissa. Ensikerran oli mahdollista piirtää toimiva tietokone ohjelma ilman koodin kirjoitusta (Suvisaari & Suvisaari, 95). Syntyneen ohjelman hitaus oli kuitenkin haitta. Teknisesti VB toimi niin, että VB-koodi toimi liimana C-kielellä kirjoitettujen VBX-komponenttien välillä, ja VBX-komponentteja voi kirjoittaa kuka tahansa. Visual Basic oli tulkattava kieli, samoin kuin Java.

Versiossa kolme oli päästy eroon hitaudesta ja mukaan oli liitetty tehokas tietokanta. Jotakin sovelluksen onnistumisesta kertoo se, että Visual Basic 3 ohjelmaa myytiin yli miljoona kappaletta (Suvisaari & Suvisaari, 95). Ohjelman ilmestymisen jälkeen lähes kaikki pikku pelit ja huviohjelmat oli kirjoitettu Visual Basic 3 ohjelmalla.

Visual Basic ohjelmointi ympäristön lomakkeelle (Form) piirretyt komponentit voidaan sitoa graafiseen dataobjektiin (Data) ja dataobjekti taas voidaan sitoa normaalin tiedostonhallinnan tyyliin tietokantaan ja sen valittuun kenttään. Yksi hiiren klikkaus objektin päällä avaa valikon, josta voidaan valita objektille ominaisista metodeista yksi ja kirjoittaa koodi.

Nykyisin yleisimmät ohjelman piirustustyökalut ovat Visual Basic 6 (kielenä Basic) ja Delphin eri versiot (ohjelmointikielenä Pascal). Kumpikin soveltuu erittäin hyvin pienten käyttöliittymäohjelmien kirjoittamiseen ja tukee olio-ominaisuuksia. VBX-komponentit on korvattu OCX-komponenteilla, jotka toimivavat kaikissa Windows 95 – Windows XP -käyttöjärjestelmän ohjelmointikielissä.

6.Luokkien visualisointi ohjelmointi työkaluissa

Ohjelmoinnin tuottavuuden vaatimukset ovat pakottaneet kehittämään yhä visuaalisempia työkaluja. Sun Microsystemsin ilmainen NetBeans on hyvä esimerkki siitä, kuinka ohjelma kokonaisuuden hallintaa voidaan helpottaa luomalla yksinkertainen puunäkymä ja yhdistämällä siihen hyvä värikoodaava editori. Valtaosa nykyisistä ympäristöistä noudattaa käyttöliittymältään ja näkymältään tätä mallia. Suosituin ilmainen vapaan lähdekoodin kehitysympäristö on tällä hetkellä Eclipse. Ympäristö kannattaa opetella, koska siihen on monipuolinen kielituki ja uudet mikro-ohjainten ohjelmointiympäristöt pääosin tukevat sitä (Prosessori 5/2006).

7. J2ME ohjelmien visualisointi

Myös kännyköiden Java-ympäristöä on pyritty visualisoimaan niin, että ohjelmakokonaisuuden ymmärtäminen on helppoa. Yllättävää kyllä, tästä on apua, vaikka puhelimiin tarkoitetut ohjelmat eivät kovin suuria olekaan.

8. CRC (Class-Responsibility-Collaboration) kortit

1980 Smalltalk ohjelmoijat kehittivät yksinkertaisen tavan visualisoida oliota, CRC kortit. Tavalliseen arkistokorttiin kirjoitettiin luokan nimi, sekä asiat joista luokka vastaa. (Fowler & Kendal, 2002)

9. Ajettavien ohjelmien visualisointi

Aloittelevat ohjelmoijat kaipaavat monesti tukea selvittääkseen yksittäisten ohjelmarivien toiminnan. Tähän tarkoitukseen on luotu erinomainen työkalu nimeltä Jeliot. Ohjelma näyttää koodin suorituksen rivi kerrallaan erittäin havainnollisesti. Ohjelmaa Linux ympäristössä käytettäessä kannattaa jättää asetuksista pois historia, sillä se hidastaa ohjelmaa kohtuuttomasti.

10.Cam-ohjelmien visualisointi

Cam-ohjelmat, joiden tehtävänä on luoda kappale jyrsimällä, sorvaamalla tai hiomalla, ovat luettavina melkoisen hankalia. Useimmissa (kalliissa) Cam-työkaluissa on kuitenkin mahdollista paitsi nähdä kappaleen muoto 3D kuvana, myös simuloida ohjelmaa, joka luo kyseisen kappaleen. Simuloidessa kuvaruudulla nähdään animaatio siitä, kuinka terä työstää kappaletta ohjelman mukaan.

Kuva10, MasterCAM käynnissä simulointi. Ohjelma näyttää komentojen toteutuksen yksi kerrallaan.

Kuva11, MasterCAM. Simulointi ohi, erivärisellä viivalla esitetään pikaliike. Kallein tapa käsitellä CNC-jyrsintä on tehdä pikaliike pöytään. Tällä keinoin voidaan aikaansaada kappaleen ja pöydän tuho.

11.Logiikkaohjelmien visualisointi

Logiikkaohjelmien kehitysympäristöjen luojat pyrkivät mahdollisimman suureen helppouteen. Koska ohjelmat ovat pieniä ja käsittelevät vain muutamia komentoja, ne on varsin helppoa toteuttaa piirrettävillä komponenteilla.

Liitteenä kuva Mitsubishin logiikan ohjelmointiympäristöstä, sekä Legon robotin ohjelmointi ympäristöstä . Selvyyden vuoksi Mitsubishin kuva esittää vain yksinkertaisia tuloja sekä lamppuja. Ympäristössä on välineet myös askelmoottoreiden, pumppujen ja ajastimien käyttämiseen.

Legon kehittämä piirrettäviin ohjelmiin perustuvassa Lego MindStorms -robotissa ohjelmakoodi visualisoidaan saman tyylisesti kuin logiikka.

12.SQL Visualisointi

Tietokantojen rakenne, relaatiot ja riippuvuudet esitetään nykyisin pääosin kuvina. Kuvaa muokkaamalla voidaan luoda SQL-kielisiä kyselyjä sekä kenttien välisiä riippuvuuksia. Kuva 15, kenttänäkymä OpenOffice 2.02 tietokanasta.

13.UML (Unified Modeling Language)

UML on määritelty objektien mallinnuskieli ohjelmiston kehittäjille. Kieltä voidaan käyttää myös organisaatioiden, liiketoimintamallien sekä laitteistojen mallinnukseen. UML ei ole menetelmä, kuitenkin se suunniteltiin yhteensopivaksi olio-ohjelmointimenetelmien kanssa. (UML ™ Resource Page, 2006)

13.1.Mallinnus

UML kaavio on osittainen graafinen kuva järjestelmästä. UML malliin voidaan kirjoittaa tekstidokumentaatiota.

Näyttää rakenteen käyttäen olioita, muuttujia, operaatioita ja luokkien välisiä yhteyksiä.

13.2.UML Kaaviot

UML 2.0 sisältää 13 kaaviotyyppiä. Ne voidaan jakaa hierarkkisesti kolmeen ryhmään.

Rakennekaaviot (Structure Diagrams) korostavat mitä mallinnettavassa järjestelmässä täytyy olla:

Käyttäytymiskaaviot (Behavior Diagrams) kertovat mitä järjestelmässä tapahtuu:

Vuorovaikutuskaaviot (Interaction Diagrams) ovat käyttäytymiskaavioiden alijoukko. Ne korostavat tiedon kulkua järjestelmän osien välillä:

Eri välineillä luotuja UML kaavioita voi vaihtaa käyttäen Diagram Interchange (DI, XMI[DI]) standardia.

13.3.Käsitteistö

Toimija (Actor), attribuutti / muuttuja (Attribute), luokka (Class), komponentti (Component), rajapinta (Interface), olio (Object), pakkaus (Package).

Tehtävä (Activity), tapahtuma (Event), viesti (Message), metodi (Method), operaatio (Operation), tila (State), käyttötapaus (Use Case).

Kooste (Aggregation), assosiaatio / yhteys (Association), vahva kooste (Composition), riippuvuus (Depends), yleistys / periminen (Generalization / Inheritance).

13.4.Muutamia esimerkkejä UML mallinnuksen käytöstä

Koska UML mallinnus on tehokas tapa helpottaa ohjelmointityötä, ohessa on muutamia esimerkkejä tärkeimmistä UML tekniikoista.

13.4.1. Käyttötapaukset

Ohjelmien suunnittelua helpottaa, jos luodaan malli käyttötapauksista (use case). UML kielessä on näiden tapausten kuvaamiseen varsin selkeät symbolit, joita kannattaa käyttää ohjelman suunnittelun alkuvaiheessa.

13.4.2.Pakettikaaviot

Pakettikaavio on välttämätön suuren projektin riippuvuuksien selvittämiseksi sekä selkeyttämään ohjelman rakennetta.

13.4.3.Luokkakaaviot

13.4.4.Tilakaaviot

Tilakaaviot ovat UML mallinnuksen sotkuisimmat elementit. Joskus niitäkin silti voi käyttää.

14.Esimerkki ohjelman kehityksestä

Helpoin tapa ymmärtää visualisoinnin merkitys on luoda esimerkki ohjelma ja esittää siinä kuinka eri menetelmiä käytetään avuksi. Esimerkkinä käytämme yksinkertaista keittokirjaa, joka kokoaa aineista ruokalajin ja laatii ostoslistan käyttäjän valitessa ruokalajit. Kannattaa miettiä kuinka kauan kyseisen ohjelman kirjoittaminen virheettömästi ottaa pelkästään konekielellä. Kunnollisilla visualisointi työkaluilla ohjelman rungon tekeminen vie kaksi päivää.

14.1.Käyttötapaus kaavio.

Ensin luodaan ohjelmasta käyttötapauskaavio, josta saadaan selville käyttöliittämän komponentit. Piirtäminen on tekninen versio ajatuskartasta.

Kuva 16, käyttötapauskaavio, josta ilmenee kaikki käyttäjän ja ohjelmiston liittymät.

Ohjelma lähettää tarjouspyynnön nettikauppaan / juoksupoika lähtee kauppaan.

14.2.Luokkakaavio

Seuraavaksi luodaan luokkakaavio, josta ilmenee kaikki ohjelman tarvitsemat luokat. Jos kaavio luodaan ammattilaistason UML editorilla, ohjelma kykenee kirjoittamaan luokkakaaviosta ohjelmakoodin. Esimerkissä käytetty VP UML 5.2 ohjelman kuukauden kokeiluversiota. Kuva 18, UML luokkakaavio.

14.3.Pakettikaavio

Seuraavaksi piirretään pakettikaavio ja selvitetään luokkien riippuvuudet. Tämän merkitys korostuu ohjelmiston päivityksen ja siirrettävyyden tarkastelussa. Kuvasta käy ilmi, kuinka käyttöliittymän komponentit ovat riippuvaisia javax.swing paketista ja tiedoston käsittely taas on riippuvainen java.io paketista. Tästä voidaan päätellä kuinka suuria vaikeuksia ohjelman siirtäminen j2me ympäristöön tuottaa.

14.4.Käyttöliittymän piirtäminen

Seuraava vaihe on käyttöliittymän piirtäminen Visual Basicin perinteitä noudattavalla työkalulla. Tässä on käytetty Sun Microsystems:in NetBeans 5.0 työkalua. Kannattaa pitää mielessä se seikka, että tähän asti luotu koodi on koneellisesti tuotettua ja moneen kertaan testattua, joten sitä voidaan pitää virheettömänä, jos kehitysvälineet ovat olleet pitkään käytössä.

14.5.Koodin kirjoitus

Kun ohjelmakokonaisuus on suunniteltu valmiiksi ja käyttöliittymä piirretty, on vuorossa ohjelmakoodin muokkaaminen. Valitettavasti tämä vaihe joudutaan tekemään käsityönä. Käytetään perinteistä värikoodaavaa editoria, joka sisältää automaattisen sisennyksen. Tässä esimerkissä on käytetty Netbeans 5.0 editoria.

14.6.Optimointi

Viimeisessä vaiheessa ohjelma optimoidaan kirjoittamalla aikakriittiset toiminnot assemblyllä. Nykyaikaiset kääntäjät ovat kuitenkin niin tehokkaita ja tietokoneiden kapasiteetti niin suuri suhteessa ohjelmiin, että tämä vaihe voidaan ohittaa, ellei kirjoiteta suuria tietokanta- tai grafiikkaohjelmia.

15.Visualisointi menetelmien vertailu

Eri menetelmien vertailu on vaikeaa, koska ne on tarkoitettu eri tilanteisiin. Vuokaavio, Lego ja Jeliot ovat opetustarkoituksiin, muut pääosin tuotanto käyttöön. UML sisältää rinnakkaisuuksia vuokaavioiden ja ajatuskarttojen kanssa, mutta näissäkin erot ovat suuremmat kuin yhteiset piirteet. Näkemyksemme mukaan kaikki esitetyt menetelmät ovat erittäin hyödyllisiä ja niiden rinnakkainen käyttö tehostaa työtä merkittävästi.

16.Tulevaisuus

Tulevaisuudessa on pakko käyttää kaikkia tässä esitettyjä visualisointi tapoja. CAD/CAM ympäristöjen kehitys on jatkunut niin kauan, että tavat tuskin muuttuvat, jos ihmisiä on mukana suunnittelussa.

Visual Basic ohjelman tyyliset ohjelman piirustustyökalut säilyvät tietokantaohjelmien käyttöliittymän suunnittelijoiden työkalupakissa vielä pitkään ja koodin värikoodaus ja sisennys eivät katoa.

Asia, jonka merkitys tulee kasvamaan voimakkaasti, on UML-kuvaus. Tulevaisuudessa ohjelmien koko ja monimutkaisuus kasvaa. Nykyisin auto sisältää 10 miljoonaa koodiriviä ja uutta koodia syntyy päivittäin vain kymmeniä rivejä. (Tietokone, 5/2006, sivu 31). Kokonaisuudessaan tulevaisuuden auto tarvitsee jo vuonna 2010 100 miljoonaa riviä koodia (Tietokone, 5/2006, sivu 6). Muut käyttöesineet tarvitsevat satojen miljoonien rivien ohjelmakokonaisuuden. Lisäksi ohjelmien on kyettävä viestimään keskenään niin, että auto voi pyytää tarjouksia bensiiniasemilta ja pesuloilta, huoltomies taas haluaa auton kertovan käyttöhistoriansa jne. Koska käyttöesineet eroavat käyttöjärjestelmistä vikakriittisyyden suhteen, kukaan ei halua auton jarrujen tai metron nopeudensäätimen kaatuvan, käyttövarmuus vaatimus on suuri. Kun tähän yhdistetään vaatimus ohjelmakomponenttien yleiskäyttöisyydestä ja ohjelmointikustannusten minimoinnista, ainoa käyttökelpoinen ratkaisu on luoda ohjelmasta UML-kuva, jonka robottiohjelma kääntää suoraan koodiksi.

Joka puolella on myös merkkejä yhteisten standardien luonnista tiedonsiirtoon verkossa niin, että ohjelmat voivat keskustella keskenään. Valitettavasti tässä ei ole edistytty muuten kuin XML-kielen osalta. Bill Gates puhui kitkattomasta kapitalismista (Gates 1995). Valitettavasti hän on myös tehnyt kaikkensa estääkseen tämän toteutumisen rikkomalla avoimia standardeja. Tulevaisuudessa tullaan kuitenkin tilanteeseen, jossa yritys, joka ei kykene toteuttamaan yritysrajapintaa verkossa, jää täysin kaupan ulkopuolelle. Siinä vaiheessa kun yritykset ovat verkon kannalta UML komponentteja, järjestelmien yhteensovittaminen muuttuu pitkistä puhelin keskusteluista ja tarjouspyyntöjen lähettämisestä yhteysviivojen piirtelyksi taustalla olevien ohjelmien hoitaessa kaupankäynnin.

On myös varmaa, ettei visualisoinnin viimeistä sanaa vielä ole nähty. Nurkan takana on uusia tekniikoita, valitettavasti emme pysty kuitenkaan kertomaan mitä.

17.Lähdeluettelo

Joensuun yliopiston tietojenkäsittelytieteen laitos. Jeliot. Internet WWW-sivu, URL: http://cs.joensuu.fi/jeliot/ (1.5.2006)

Koisaari, Tapio: Tietotekniikka muovaa uudenlaista autoa, Tietokone, 06(5): 26-31, 2006

Ojanperä, Veijo: Lisää ytimiä ja virtuaalisia alustoja, Prosessori, 06(5): 44, 2006

OpenOffice org. OpenOffice 2.02 tietokanta, Internet WWW-sivu, URL: www.openoffice.org (1.5.2006)

Suvisaari S., Suvisaari O.: Visual Basic - Ohjelmoijan opas, Suomen ATK kustannus Oy, Jyväskylä, 1995

UML org. UML™ Resource Page. Internet WWW-sivu, URL: http://www.uml.org/ (1.5.2006)