You are on page 1of 9

2.2.

Tietokoneohjelman tekeminen
7.1.2008. pva, kuvat jma

”Nothing is particularly hard if you divide it into small jobs.”


- Henry Ford

Yleistä

Tietokone tekee kaiken sen - ja vain sen - mitä ohjelmoija ohjelmassa määrittää. Ohjelma on
tietokoneen toimintaohje, joka koostuu peräkkäisistä komennoista eli käskyistä. Käskyt on tallennettu
ohjelmamuistiin, josta ne haetaan yksi kerrallaan ja viedään mikroprosessorin käskynkäsittely-
yksikköön, jossa ne tulkitaan ja tehdään käskyn määräämä pieni, hyvin yksinkertainen toiminto.
Riittävän paljon erilaisia pieniä toimintoja, hyvin, hyvin nopeaan tahtiin peräjälkeen suoritettuna
muodostaa ajettavan ohjelman.

Kuva 2.2.1. Koneellisen tiedonkäsittelyn idea.

Ohjelmia on joka lähtöön. Yksi mahdollistaa kännykän puheliikenteen, toinen punnitsee kaupan
hedelmätiskillä banaanipussin painon ja kolmas laskee ostoksen hinnan ja vielä tulostaa
viivakooditarran.

1
2.1. Tietokoneohjelman tekemisen eri vaiheet

Ensiaskel ohjelmien laatimisen opiskelussa on perehtyä ja jäsentää ajatteluunsa oikeat ohjelman


tekemisen metodit. Seuraavat sivut kannattaa lukea nyt huolella ja myöhemmin, sitten kun hieman
ohjelmointikokemusta on kertynyt, kerrata ne omaksumisen tasolle.

Tutkitaan ohjelmantekoprosessia ensin kaaviokuvalla. Kuvahan kertoo enemmän kuin sata sanaa. Sen
avulla voi nopeasti hahmottaa monimutkaisiakin asioita, siis mitä ollaan tutkimassa tai tekemässä.

Kuva 2.2.2. Tietokoneohjelman tekemisen eri vaiheet.

Kaikki alkaa suunnittelusta

On hyvin tärkeää, että ohjelma oikeasti suunnitellaan, eikä vaan ajauduta summittaisen yritys- ja
erehdys-systeemin kautta epätoivoon. Kunnollinen suunnittelu antaa työskentelyyn ryhtiä ja luo
kestävän perustan jolle varsinainen koodi rakennetaan. Aivo- ja käsityönä. Suunnittelu tulee tehdä
ensimmäisenä, ennen ensimmäisenkään koodirivin kirjoittamista.

Kokemus on osoittanut, että ohjelma kannattaa suunnitella ’ylhäältä alas’, top down. Hahmotetaan
ensin kokonaisuus ja jaetaan sitten tämä pienempiin, helpommin hallittaviin osiin, moduuleihin. Jos
moduulit suunnitellaan itsenäisiksi toimintakokonaisuuksiksi, joista voi kirjoittaa itsenäisiä funktioita,
niin varsinainen koodin kirjoittaminen ja testaaminen helpottuu oleellisesti.

Toisinkin voi tehdä.

2
Varsinkin sulautetuissa järjestelmissä asia voidaan, ja joskus kannattaakin (riippuu tapauksesta), tehdä
toisin päin, alhaalta ylös. Jos tehdään esimerkiksi termostaatti, tehdään ensin mittaussysteemi, joka
testataan huolellisesti. Sitten tehdään erikseen asetusarvon syöttö, ja toimilaitteen ohjaus, jotka samoin
testataan. Lopuksi kirjoitetaan pääohjelma, joka vain mittaa, vertaa ja ohjaa.

Jokainen ymmärtää, että suunnitteluprosessi on aivan erilainen, jos kännykkätehtaan ympäri maailmaa
hajautetut asiantuntijaryhmät pitää ohjata tekemään uutta matkapuhelinsukupolven ohjelmaa, tai jos
yksinäinen koodaaja päättää tehdä ohjelman (ja elektroniikan), joka pyörittää tuuletinta lämpötilan
ylittäessä tietyn raja-arvon. Ensimmäinen on hyvinkin pitkä, erittäin sosiaalinen ja moniulotteinen
prosessi, jälkimmäinen individualistin yksinäistä puuhastelua.

1. Tehtävän määrittely, analyysi

Aluksi on viisainta jäsentää tietokoneelle annettavaa tehtävää yksityiskohtaisesti, kirjoittamalla se


”selväkielisenä” paperille. Tai oikeastaan ehkä nykyään teksturilla kuvaruudulle. Analysoidaan eli
selvitetään mikä on ongelma joka ohjelmalla on tarkoitus hoitaa. Siis mitä ohjelmalla pyritään
tekemään.

Ajatellaanpa tovi miten kotoinen leipuri toimii.


Hänen arkinen tehtävänsä voi olla vaikka valmistaa sokerikakku. Aluksi hän pohtii, kuinka suuri kakku
eli montako vierasta tulee, mitä työvälineitä ja raaka-aineita tarvitaan ja kuinka paljon, onko niitä
valmiina hyllyssä vai pitääkö ostaa/lainata, onko uuni riittävän lämmin jne. Hän analysoi eli jäsentää
kakun valmistusprosessia, siis pohtii mitä kaikkea pitää tehdä ja missä järjestyksessä ennen kuin herkku
on valmis kahvipöytään.
Kakun tekemisestä luodaan, ellei paperille, niin ainakin päässä, algoritmi. Vaikka tuskin leipuri sitä
nimeä käyttää.

Mikro-ohjaimen ohjeet tehdään aivan samalla tavalla. Analyysi tehdään ’selväkielisenä’. Varsinainen
tehtävä on ensin jaettava sellaisiin osiin, jotka ohjelmassa suoritetaan erikseen.
Tapauksesta riippuen, mietitään mm:
- millaisiin osiin, moduuleihin, tehtävä kannattaa jakaa
- mitä I/O-portteja ja/tai oheiskomponentteja tarvitaan
- tarvitaanko käyttöjännitteen lisäksi muita jännitteitä
- tarvittavien syöttö- ja tulostustietojen/ohjaussignaalien muotoa ja sisältöä
- mitä tulevalle tiedolle tehdään, mihin pyritään, mitä sillä ohjataan
- mietitään erikoistapaukset
- mitä tehdään, jos ’jokin menee pieleen’

Näiden perusteella kirjoitetaan algoritmi.

3
2. Algoritmi

Algoritmi vastaa kysymykseen, ’mitä pitää tehdä ja missä järjestyksessä, jotta tavoite
saavutetaan?’

Se on kuvaus toimenpiteistä, joiden avulla tietokone tehtävän suorittaa. Algoritmilla kuvataan


ongelman ratkaisu niin yksinkertaisina loogisina askeleina, että sen perusteella voidaan kirjoittaa
ohjelma. Kakun tekemiseen riittää ylimalkaiset ohjeet, sillä ihminen pystyy järkeilemään epätarkatkin
sanonnat (’ripaus’, ’hyppysellinen’, ’maun mukaan’).
Tietokone ei tähän pysty. Siksi sille pitää kirjoittaa pilkuntarkat ohjeet.

Algoritmin idean oppiminen ja hyödyntäminen lienee vaikein osa ohjelmoinnin


oppimista. Aiheesta on kirjoitettu useita kirjoja. Niihin kannattaa tutustua. Mutta
vasta myöhemmin, kun ohjelmoijalla on tarpeeksi pohjatietoa asian omaksumiseen.

Uusi tieto tarvitsee tartuntapintaa.


Sulautettuihin systeemeihin ensiaskeleitaan ottavan tulee hallita ainakin algoritmien
perusteet. Ne tulevat tässä.

Algoritmin kirjoittaminen
Ongelman ratkaisun kuvaus voidaan tehdä monella eri tavalla.

1. Matemaattinen malli
- esimerkkinä vaikka lukujärjestelmämuunnokset.

2. Vuokaavio
- joka etenee kuva kuvalta kohti ratkaisua.

3. Pseudokieli, -koodi
- lopullista ohjelmakoodia jäljittelevää tekstiä

Parasta opetella käyttämään yhtä kirjoittamismallia kunnolla. Tällöin valinta(ehdotukseni) on


pseudokieli, koska siinä tehtävän jäsentelyn ohessa syntyy ohjelmalauseiden alkioita. Toisaalta
pseudokoodin kirjoittaminen on saanut yhä lisääntyvää suosioita ohjelmoijien keskuudessa.

Pseudokieli

Pseudokieli on selväkielistä tekstiä, siis ihmiselle tarkoitettu kuvaus mitä ollaan tekemässä. Se on
sekoitus suomea (englantia) ja C-kielen termejä, joilla kuvataan tehtävän suoritusaskeleet. Jokaisesta
moduulista (funktio) kirjoitetaan oma pseudokoodi.

4
Pseudokoodin kirjoittaminen aloitetaan sitten, kun ensin on selvitetty perusteellisesti, mikä on ongelma,
mitä ollaan tekemässä, mikä on toimintaympäristö, mitä se edellyttää ohjelmalta. Esim. kännykän
ohjelman tekemisessä itse koodin kirjoittaminen sujuu, kunhan ensin on kirjoitettu toimiva algoritmi
(tai oikeastaan toimivat algoritmit). Sen tekeminen on suuritöinen ja vaikeasti hallittava prosessi, koska
ensin pitää selvittää järjestelmän toiminta, mitä kaikkia signaaleja ja datoja se käsittää, millaisia ne
ovat, millä ajanhetkellä ja millä ehdoilla ne ovat voimassa, mitä niille voi ja saa ja pitää tehdä ja
milloin, jne.

Algoritmi kannattaa kirjoittaa pseudokoodiksi, sillä se on lähimpänä lausekielistä ohjelmarakennetta ja


siten jatko on vähätöisempää. Tärkeää on jakaa monimutkainen tehtävä, task, lohkoiksi, eli
osatehtäviksi. Jos on tarvetta, nämä jaetaan edelleen pienemmiksi osatehtäviksi, kunnes päädytään
helposti ratkaistavaan 'pikku ongelmaan'.
Kun pseudokielen avulla on luotu kuvaus tehtävästä, niin sitten sen kääntäminen ja kirjoittaminen
varsinaiseksi lähdekoodiksi on helppoa. Tai ainakin se on vähemmän vaikeaa.

Tässä mahdollisimman yksinkertainen esimerkki, joka selvittää asiaa. Toinen esimerkki,


perusteellisempi, on kirjan lopussa, jossa käydään läpi kännykkään liittyvä harjoitusprojektityö.

Tehtävä:
Mikrotietokoneella mitataan huoneen lämpötila minuutin väliajoin, tallennetaan arvot muistiin ja
tulostetaan ne LCD-näyttöön. Jos raja-arvo ylittyy, annetaan hälytys.

Pseudokoodi

Alku
luo taulukko
ja aseta rekisterit alkuarvoihin // CPU, keskeytys- ja timer-rekisterit ja LCD-näyttö

repeat(1) // toista niin kauan kuin


{
mittaa_aikaa,
kun minuutti kulunut
read anturi() // lue lämpötila-anturi
laske_asteet() // muuta lukema Celcius-asteiksi
talleta taulukkoon()
tulosta_asteet() // tulosta näyttöön
jos
aste > raja-arvo // testi
anna_halytys()
}

Sama asia voidaan esittää vuokaaviona esimerkiksi näin.

5
Kuva 2.2.3. Vuokaavioesitys.

Algoritmi kirjoitetaan ihmisen ajattelua varten, mutta koko ajan miettien, miten työ on tietokoneella
tehtävissä. Hyvin tehdystä algoritmista on helppoa kirjoittaa itse ohje, eli ohjelma tietokoneelle.
Parhaimmillaan ohjelmalauseet vain ’pudotellaan’ ruudulle algoritmin ohjaamana.

3. Lähdekoodin kirjoittaminen

Ulkopuoliselle ohjelmointi näyttää tietokoneen ääressä istumiselta ja ’cokiksen’ juomiselta, mitä nyt
välillä naksutellaan näppäimistöä. Mutta se on aivan muuta.

Tavallaan ohjelmointi on algoritmin kääntämistä ohjelmointikielelle.


Algoritmin kääntäminen tapahtuu pääasiassa ohjelmoijan päässä. Siksi työ vaatii häiriöttömän
työskentely-ympäristön ja edellyttää syvää keskittymistä. Harmaat aivosolut on viritettävä hallitusti
maksimisuoritukseen. Jos tehtävästä on kirjoitettu hyvä algoritmi, silloin asiaa on selvästikin
syvällisesti mietitty ja itse ohjelman kirjoittaminen on vähemmän työlästä, etten sanoisi helppoa.
Ainakin se on antoisaa.

6
Tietokoneelle annettavien toimintaohjeiden on oltava yksityiskohtaisia ja yksikäsitteisiä, konkreettisia.
Sokerikakun tekijälle riittää suurpiirteinen, abstrakti ohje.

Virheettömän koodin tekeminen ensimmäisellä kirjoittamiskerralla onnistuu harvoin. Usein jäädään,


ainakin joksikin aikaa, ’kolmen koon silmukkaan’: kirjoita, käännä, kokeile. Mitä lyhyempi tämä
silmukka on, sitä parempi. Älä kirjoita pitkää koodia yhteen menoon, vaan käännä ja testaa mielellään
yksi funktio kerrallaan. Vian ilmetessä muuta lähdekoodia vain yhdestä kohtaa. Muuten on vaikea
todeta, mikä toimenpide oikeastaan virheen poisti. Tai aiheutti niitä lisää.
Jos yhden funktion lauseet eivät mahdu kerralla kuvaruudulle, koodi on todennäköisesti liian pitkä ja
siten liian vaikeasti hallittavissa. Palastellaan ongelmaa lisää muodostamalla uusia funktioita, siten
ratkaisun löytyminen helpottuu.

Ohjelma:
- aluksi kirjoitetaan ohjelma jollakin ihmisen ymmärtämällä ohjelmointikielellä
- sitten se käännetään käänninohjelmalla tietokoneen ymmärtämäksi konekieleksi.

Itse ohjelma voidaan toteuttaa millä kielellä tahansa, kunhan sille löytyy käytettävälle
mikro-ohjaimelle koodia tekevä käänninohjelma.

4. Lähdekoodin kääntäminen

Ohjelman lähdekoodi kirjoitetaan jollain editorilla ja käännetään käänninohjelmalla konekielelle eli


mikroprosessorin ymmärtämään muotoon. Jos lähdekoodi ei ole C-kielen kieliopin sääntöjen mukaista,
käänninohjelma keskeyttää kääntämisen ja antaa virheilmoituksen. Usein tämä virheilmoitus on ’älykäs
arvaus’, virhe voi olla ilmoituksen mukainen, ’tai jossain siellä päin’. Tutki ilmoitus tarkkaan ja
mietinnän jälkeen korjaa virhe, yksi kerrallaan. Jos virheitä on monta, aloita aina ensimmäisestä.
Useimmiten tämän jälkeen virheiden määrä vähenee oleellisesti.

Usein C-käännin generoi varsinaisen käännetyn koodin lisäksi monta muuta tiedostoa. Niitä voi
hyödyntää ohjelmavikojen etsinnässä tai koodin toiminnan optimoinnissa.

5. Mikro-ohjaimen ohjelmointi

Ajokelpoinen koodi on siirrettävä PC:n muistista mikro-ohjaimen ohjelma-muistiin. Sen tekee erityinen
latausohjelma (ohjelmointiohjelma), joka siirtää koodin PC:ltä kirjoitin-, sarja-, tai USB-portin kautta
ohjelmointikaapelia pitkin mikro-ohjaimen ohjelmointiliitäntään. Harvemmin nykyään käytetään
erillistä ohjelmointilaitetta.

Ohjelma:
- sellaisia peräkkäisiä binäärilukuja (ykkösiä ja nollia) ohjelmamuistissa,
jotka CPU osaa tulkita transistorien ohjausjännitteiksi.

7
6. Ohjelman testaus ja virheiden etsintä, debuggaaminen

Ohjelman loogiset virheet tulevat esille vasta ajamalla sitä oikeassa toimintaympäristössä. Jos nyt
ilmenee virheitä, taas on miettimisen paikka. Korjaa virhe vasta, kun tiedät tarkalleen, mikä sen
aiheuttaa ja miten se korjataan. Muuten saattaa tapahtua niin, että ’korjauksen’ seurauksena syntyy
uusia, entistä vaikeampia virheitä.

Testauskin kannattaa tehdä palasina. Siis ohjelmaa pitää testata kaiken aikaa, sitä mukaa kuin se
valmistuu. Jos suinkin mahdollista funktio kerrallaan. Silloin ongelmien ilmetessä ei niitä tarvitse etsiä
suuresta koodikokonaisuudesta, vaan vian etsiminen voidaan kohdistaa pieneen, tarkasti määriteltävään
ohjelman osaan. Kun kaikki moduulit on valmiina ja yksittäin testattuna, kokonaisuuden testaus tuskin
aiheuttaa ongelmia.

Ohjelmavirheet ovat bugeja ja siten de-buggaaminen on virheiden etsimistä ja korjaamista. Siihen on


tehty moninaisia työkaluja. Niitä sanotaan debuggereiksi.

Simulaattori
on eräs tällainen testaustyökalu, se matkii mikro-ohjaimen toimintaa. Simulaattori on PC:ssa ajettava
ohjelma, jonka avulla testataan ohjelman toiminta (etsitään mahdolliset virheet) ennenkuin itse
”sulautettua rautaa” on saatavillakaan.

Emulaattori
on toinen tärkeä testaus- ja debuggaustyökalu. Siinä tutkittava ohjelma ajetaan oikeassa ympäristössä,
tässä tapauksessa AVR-mikro-ohjaimessa. Emulaattori tuo PC:n ruudulle näkyviin kaiken mitä mikro-
ohjaimen sisällä rekistereissä tapahtuu, siis juuri testattavassa laitteessa ja reaaliajassa.
o ohjelmakoodia voidaan ajaa AVR:ssa käskyrivi kerrallaan
o ohjelmasuoritus voidaan pysäyttää jonkin ehdon perusteella (breakpoint)
o suorituksen aikana voidaan seurata ja muutella
 rekistereitä, I/O-portteja
 muistipaikkoja
 muuttujia

Erikoisesti ohjelmoinnin opiskelussa emulaattori on kelpo apulainen. Samalla sen avulla opitaan
tehokkaasti mikro-ohjaimen toiminta (”mitä siellä CPU:ssa oikeesti tapahtuu”).

7. Ohjelman dokumentointi ja ylläpito

Dokumentointi on tärkeä osa ohjelmaprojektia, varsinkin jos tehdään isompaa, aikaa ja monta
ohjelmoijaa vaativaa työtä. Ilman kunnon dokumentointia ohjelman ylläpito (päivitykset, muutokset,
korjaukset) on lähes mahdotonta. Sen merkityksestä saa käsityksen kun tietää, että (muille) hyödyllisen
dokumentin tekeminen vie aikaa usein enemmän kuin itse koodin kirjoittaminen. Siksi isoissa
ohjelmistoprojekteissa on kullakin ohjelmoijaryhmällä (noin tusina ammattilaisia) oma laatuinsinööri.

8
Hän on henkilö joka valvoo, että kukin koodaaja tekee yhtiön normin mukaista koodia ja samalla
kunnon dokumentointia työstään ja että se vielä valmistuu ajallaan.
Jos aikoo ammattilaiseksi, pitää heti opetella oikeat työmenetelmät. Pienissäkin projekteissa
dokumentin tekeminen kannattaa aloittaa samanaikaisesti itse ohjelman suunnittelun kanssa.
Lopputuloksen tulee olla sellainen, jota itse kaipaa silloin, kun ottaa toisen tekemän ohjelmiston
vastuulleen.

Mitä tietoja kunnollinen dokumentaatio sisältää?


Ainakin tämän:

1. Tiedot ohjelmasta
- ohjelman nimi ja ohjelman tekijä ja päivämäärä
- mikro-ohjain, jolle ohjelma kirjoitettu
- mihin tarkoitukseen ohjelma on tehty, mitä se tekee

2. Ohjelman rakenne
- yleinen rakenne
- pääohjelma main() ja funktiot
- yksityiskohtainen rakenne pseudokoodina
- C-kielinen ohjelman listaus
- lähtö- ja tulostiedot

3. Ohjelman testaus
- testiaineisto

Yhteenveto ohjelman tekemisestä

1. Kirjoita idea teksturilla ”näkyville” ja ”väyrystele”


- miksi ohjelma kannattaa/tulee tehdä?

2. Laadi ideasta algoritmi


- mitä ohjelma tekee ja miten?

3. Algoritmin pöytätestaus, pseudokoodin kirjoitus


- menikö kaikki oikein?

4. Ohjelman tekeminen/kirjoittaminen (pseudokoodista) ja testaus


- tekeekö ohjelma haluttuja asioita, onko korjattavaa?
- syntyykö ohjelman toiminnan pohjalta lisää ideoita?

5. Jos lisää ideoita tai ohjelmaa pitää muuttaa/parantaa, siirry kohtaan 2

Väyrystellä = nukkua yön yli

You might also like