Jyväskylän yliopisto Tietotekniikan laitos Luentomoniste 11

University of Jyväskylä Department of Mathematical Information Technology Lecture Notes 11

 

 

 

 

 

 

 

 

 

OHJELMOINTI 2

       

uudistettu painos

 

Vesa Lappalainen ja Santtu Viitanen

 

 

 

 

 

 

 

 

 

 

 

 

Raino A. E. Mäkinen

Jyväskylän yliopisto

Tietotekniikan laitos

PL 35 (Agora)

40014 Jyväskylän yliopisto

fax (014) 260 4980

http://www.mit.jyu.fi

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2012 Vesa Lappalainen, Santtu Viitanen ja

Jyväskylän yliopisto

ISBN  978-951-39-4624-1 (uudistettu painos)

ISSN 1456-9787

 

Jyväskylän yliopistopaino

Jyväskylä 2012

Lukijalle

Alkuun annan sulle vinkin, joutavia on juorut muiden:   Luppo loppui, alkoi arki, kutsuu koulu - niinkö luulet? Uskoppas: YLIOPISTO vaatii työtavat totiset!   Ostolla oppi ei tulene eikä kauhan kaadannalla, myös ei vastuun välttämällä, työnsä muilla teettämällä   Jos sun mielesi tekevi, aivosi odottelevi, vilauttaa vinkin voinen, opastukset ongelmille.

Pakko tehdä on demoja, harjoitukset harjoitella, itse illoin ihmetellä, kovin koodailla kotona.   Harjoitustyö haastavasta, syntyy aiheesta omasta, kokonaisuuden kuvaksi, metsän puilta mieltäväksi.   Luontune ei kurssi yksin: moni meitä auttamassa, ohjaajat opastamassa, valistaen vaadittaissa.   Toki saarnailen salissa, kerron joukolle jotakin, esimerkkejä esitän ynnä vaiheita valotan.

 

Tämä moniste on tarkoitettu oheislukemistoksi Ohjelmointi 2-kurssille.  Vaikka monisteen yksi teema onkin Java-kieli, ei kieli ole monisteen päätarkoitus.  Päätarkoituksena on esitellä ohjelmointia.  Esitystavaksi on valittu yhden ohjelman suunnitteleminen ja toteuttaminen alusta lähes loppuun saakka.  Tämä Top-Down -metodi tuottaa varsin suuren kokonaisuuden, jonka hahmottaminen saattaa aluksi tuntua vaikealta. 

Kunhan oppii kuitenkin katsomaan kokonaisuuksiin yksityiskohtien sijasta, asia helpottuu.  Yksityiskohtia harjoitellaan monisteen esimerkeissä (Bottom-Up), joista suuri osa liittyy monisteen malliohjelmaan, mutta jotka silti voidaan käsittää mallista riippumattomina palasina.

Monisteen ohjelmat on saatavissa myös elektronisesti, jotta niiden toimintaa voidaan kokeilla kunkin vaiheen jälkeen.

Java-kieltä ja sen ominaisuuksia on monisteessa sen verran, että lukijalla on juuri ja juuri erittäin pienet mahdollisuudet selvitä ilman muuta kirjallisuutta. 

Lukijan kannattaakin ilman muuta hankkia ja seurata tämän monisteen rinnalla jotakin varsinaista Java-ohjelmointikirjaa. Hyvä kotimainen vaihtoehto on esimerkiksi: Jorma Kyppö, Mika Vesterholm: Java-ohjelmointi, 2008, Talentum Oyj. Myös ohjelmointiympäristön mukana olevasta OnLine-avustuksesta (Help) saa tarvittavaa lisätietoa.

Monisteen esimerkkiohjelmat löytyvät elektronisessa muodossa:

Edellä mainittuun polkuun lisätään vielä ohjelman yhteydessä mainittu polku.

Monisteessa on lukuisia esimerkkitehtäviä, joiden tekeminen on oppimisen kannalta lähes välttämätöntä.  Vaikka lukija saattaa muuta kuvitellakin, ovat monisteen vaikeimmat tehtävät monisteen alussa.  Mikäli loppupuolen tehtävät tuntuvat vaikeilta, ei monisteen alkuosa olekaan hallinnassa.  Siksi kehotankin lukijaa aina vaikeuksia kohdatessaan palaamaan monisteen alkuosaan; siitä ei monikaan voi sanoa, ettei asioita ymmärtäisi.

Lopuksi kiitokset kaikille työtovereilleni monisteen kriittisestä lukemisesta.  Erityisesti Tapani Tarvainen on auttanut suunnattomasti C-kieleen tutustumistani ja Jonne Itkonen vastaavasti tutustumista Java ja C++-kieleen ja olio-ohjelmointiin.

Alkuperäinen versio allekirjoitettu Palokassa 28.12.1991

Monisteen 3. korjattuun painokseen on korjattu edellisissä monisteissa olleita painovirheitä sekä lisätty lyhyt C-kielen "referenssi".  Lisäksi kunkin esimerkkiohjelman alkuun on laitettu kommentti siitä, mistä tiedostosta lukija löytää esimerkin.  Myös hakemistoa on parannettu vahventamalla määrittelysivun sivunumero.

Palokassa 28.12.1992              

Monisteen 4. korjattuun painokseen on jopa vaihdettu monisteen nimi: Ohjelmointi++, kuvaamaan paremmin olio-ohjelmoinnin ja C++:n saamaa asemaa.  Tätä kirjoittaessani moniste ei ole vielä kokonaan valmis ja kaikkia siihen tulevia muutoksia en vielä tässä pysty luettelemaan.

Joka tapauksessa olen monisteeseen lisännyt tekstiä - valitettavasti nimenomaan ohjelmointikieleen liittyvää - jota vuosien varrella olen huomannut opiskelijoiden jäävän kaipaamaan.  Lisäksi kunkin luvun alkuun on lisätty suppea luettelo luvun pääteemoista ja luvussa esiintyvistä kielen piirteistä sekä niiden syntaksista.  Tämä syntaksilista on helppolukuinen "lasten" syntaksi, varsinainen tarkka ja virallinen syntaksi pitää katsoa kielen määrityksistä.

Ohjelmalistauksiin on lisätty syntax-highlight, eli kielen sanat on korostettu ja näin lukijan toivottavasti on helpompi löytää mitkä termit on itse valittavissa ja mitkä täytyy kirjoittaa juuri kuvatulla tavalla.  Myös joitakin vinkkejä on lisätty. Pedagogisesti on vaikea päättää saako esittää virheellisiä tai huonoja ohjelmia lainkaan, mutta vanha viidakon sananlasku sanoo että "Viisas oppii virheistä, tavallinen kansa omista virheistä ja tyhmä ei niistäkään".  Siis mahdollisuus "viisaillekin" ja nämä virheelliset ohjelmat on merkitty surullisella naamalla: ☹.  Näin aivan jokaisen ei tarvitse rämpiä jokaista sudenkuoppaa pohjia myöten ominpäin.

Olio-ohjelmointi on kuvattu esimerkkien avulla ja varsinainen oliosuunnittelu - joka on erittäin tärkeää - on jätetty erittäin vähälle.  Suosittelenkin lukijalle jonkin oliosuunnitteluun liittyvän kurssin käymistä tai kirjan lukemista.

Myös tätä kurssia edeltävä kurssi Ohjelmoinnin alkeet  on kokenut muutoksia ja vaikka kurssi meneekin nykyisin entistä pitemmälle, ei tästä monisteesta ole kuitenkaan poistettu kaikkea päällekkäisyyttä Ohjelmoinnin alkeet -monisteen kanssa.  Toimikoon nämä päällekkäisyyden kertauksena ja kohtina, joissa luennoilla voidaan asia sivuttaa nopeammin.  Joka tapauksessa lukijan kannattanee pitää myös Ohjelmoinnin alkeet -moniste tämän monisteen rinnalla.

Palokassa 5.1.1997

Monisteen 5. korjattuun painokseen on korjattu pieniä kirjoitusvirheitä ja epätäsmällisyyksiä.  Samalla on poistettu hieman C-esimerkkejä ja yritetty enemmän jättää jäljelle esimerkkejä siitä, kuinka käytännössä kannattaa tehdä.  Nyt erityisesti kurssia myös pitänyt Antti-Juhani Kaijanaho on antanut merkittävästi palautetta monisteesta.

Palokassa 30.12.2001 

Monisteen uusi painos on kirjoitettu C++:n sijasta Java-ohjelmointia silmällä pitäen.

Monisteessa olevat Kalevala-mittaiset runot ovat syntaksin mukaisia.  Lukija voi itse päättää riittääkö se.  Sama pätee ohjelmoinnissa.  Syntaktisesti oikea ohjelma on vielä kaukana toimivasta ohjelmasta.

Palokassa 30.12.2002

Monisteen vuoden 2012 versioon on lisätty graafisen käyttöliittymän tekeminen Swing-kehyksellä sekä korjattua lukuisia pieniä yksityiskohtia.  Kiitoksia Santtu Viitaselle tehdystä työstä.

Palokassa 25.12.2011

                                                                                                                     Vesa Lappalainen

 

 

 

 

 

Alkoi kurssi, alkoi uusi

tuska tuli, moni jo huusi:

Javaa jankuttaa tuo ukko

syntaksia sammaltaapi.

 

Tokko tavalla tuollasella

ohjelmoimaan oppimahan

Java kieltä pänttämähän

Ceetä kalloon taikomahan.

 

Arvelee, ajattelevi,

pitkin päätänsä pitävi:

Ei oo ulkoo oppimista,

kieli väkisin vääntämistä.

 

Pohtimaan pitää heretä

ongelmia oikomahan

sulamahan suunittelu

pohja vankaksi valaman.

 

Tämän monisteen tarkoituksena on toimia tukimateriaalina opeteltaessa sekä algoritmisen että olio-ohjelmoinnin alkeita.  Aluksi meidän tulee ymmärtää mitä kaikkea ohjelmointi pitää sisällään.  Aivan liian usein ohjelmointi yhdistetään päätteen äärellä tapahtuvaan jonkin tietyn ohjelmointikielen koodin naputtamiseen.  Tämä on ehkä ohjelmoinnin näkyvin, mutta myös toisaalta mekaanisin ja helpoin osa.

Ohjelmointi voidaan jakaa esimerkiksi seuraaviin vaiheisiin: 

•  tehtävän saaminen

•  tehtävän tarkentaminen ja tarvittavien toimintojen hahmottaminen

•  ohjelman toimintojen ja tietorakenteiden suunnittelu, oliosuunnittelu

•  yksityiskohtaisten olioiden ja algoritmien suunnittelu

•  OHJELMOINTITYÖKALUN VALINTA

•  algoritmien/luokkien metodien tarkentaminen valitulle työkalulle

•  ohjelmakoodin kirjoittaminen

•  ohjelman testaus

•  ohjelman käyttöönotto

•  ohjelman ylläpito

 

Kannattaa huomata että listalla varsinaisesti tietokoneella tehtävä työ on listan viimeisissä kohdissa. Pitkään ohjelmistojen suunnittelu ja toteutus seurasivatkin orjallisesti vaihe vaiheelta yllä olevan kaltaista listaa. Tämä vesiputousmalliksi kutsuttu toteutustapa oli ennen ohjelmistokehityksen kulmakivi, jolla toteutettiin käytännössä kaikki ohjelmointiprojektit. Maailmalla ilmestyi kuitenkin tutkimuksia joiden mukaan suurin osa ohjelmistoprojekteista itse asiassa epäonnistui, mikä tietysti on hälyttävää millä tahansa alalla.

Nykyään perinteisen vesiputousmallin rinnalle on noussut niin sanottu ketterä ohjelmistokehitys (Agile Software Development). Se on joukko menetelmiä joiden leimaavin piirre on ohjelmien kehittäminen pienissä pätkissä, joissa jokaisessa toteutetaan kaikki ohjelmistokehityksen vaiheet. On jopa mahdollista että yksi ihminen työstää useaa vaihetta kerralla! Ketterillä menetelmillä on oma julistus, Agile Manifesto, jonka arvoja ne pyrkivät noudattamaan.

•  Yksilöt ja vuorovaikutus yli prosessien ja työkalujen

•  Toimiva ohjelma yli kokonaisvaltaisen dokumentaation

•  Asiakasyhteistyö yli sopimusneuvottelujen

•  Muutoksiin vastaaminenyli suunnitelman seuraamisen

 

Tavoitteita tulkittaessa täytyy kuitenkin muistaa, että vaikka menetelmät pitävätkin lihavoituja asioita arvokkaampana, niin ne eivät tee silti muista merkityksettömiä.

Vaikka tavoitteet ovatkin yhteneväiset, niin menetelmien väliset erot ovat usein suuria. Jotkut saattavat painottuvat projektinhallintaan, kun taas joku tarjoaa käytännön ohjeita ohjelmoijan työskentelytapoihin.

Tämän kurssilla opetuksessa ja varsinkin harjoitustyön toteuttamisessa pyritään mahdollisuuksien mukaan soveltamaan ja lainaamaan paljon niin sanotulta Extreme Programming (XP) menetelmältä. Tietenkin menetelmä on kehitetty työelämän tarpeisiin, eikä sen soveltaminen sellaisenaan opetuskäyttöön ole mahdollista.

•  Iteraatiot

•  Aiemmista kokemuksista oppiminen

•  Testilähtöinen ohjelmointi

•  Pariohjelmointi

•  Uudelleenrakentaminen

•  Yhteisomistajuus

•  Jatkuva integrointi

•  Et tule tarvitsemaan sitä (yksinkertainen rakenne)

•  Hallinnon (opettajat ja ohjaajat) taustatuki

•  Tasainen työtahti

•  Julkaisujen suunnittelu

•  Hyväksyntätestaus

•  Lyhyin väliajoin tuotettavat julkaisut (pienet julkaisut)

 

 

Aluksi kurssi keskittyy ohjelmoinnin perusteiden, kuten algoritmien ja oman ohjelman suunnitteluun. Nykyisin suunnittelun alkuvaiheessakin tarvittava dokumentointi ja ideoiden sekä vaihtoehtojen kirjaaminen tehdään käyttäen tekstinkäsittelyohjelmia ja/tai kaavioiden piirtoa piirto-ohjelmilla.  Varsinaisesta koodauksesta ei kuitenkaan alkuvaiheessa ole kysymys.

Ohjelman kehityksen eri vaiheissa saatetaan tarvittaessa palata takaisin alkumäärityksiin.  Kuitenkin ohjelman valittujen toimintojen muuttaminen oman laiskuuden tai osaamattomuuden takia ei ole suotavaa.  Ei saa lähteä ompelemaan kissalle takkia ja huomata, että kangas riittikin lopulta vain rahapussiin.

Usein ohjelmointikursseilla unohdetaan itse ohjelmointi ja keskitytään valitun työkalun - ohjelmointikielen - esittelyyn.  Ajanpuutteen takia tämä onkin osin ymmärrettävää.  Kuulijat kuitenkin hämääntyvät, eivätkä ymmärrä luennoitsijan tekevän edellä kuvatun listan kaltaista suunnittelutyötä myös kunkin pienen malliesimerkin kohdalla.  Kokenut ohjelmoija saattaa pystyä hahmottamaan ongelman ratkaisun ja tarvittavat erikoistapaukset päässään silloin, kun on kyse erittäin lyhyistä malliesimerkeistä.  Jossain vaiheessa ohjelmoinnin oppimista suunnittelu ja koodin kirjoittaminen tuntuvat sulautuvan yhteen. 

Opiskelun alkuvaiheessa on kuitenkin syytä keskittyä nimenomaan ongelman analysointiin ja ohjelman suunnitteluun.  Tässä paras apu on usein terve maalaisjärki.  Mitä vähemmän ymmärtää itse ohjelmointikielistä, sitä vähemmän kielet rajoittavat luovaa ajattelua.

Usein ohjelman suunnittelu voidaan aloittaa jopa käyttöohjeen kirjoittamisella!  Tällöin tulee tutkituksi ohjelmalta vaaditut ominaisuudet ja toimintojen loogisuus sekä helppokäyttöisyys!  Nykytyökaluilla voidaan myös rakentaa suhteellisen helposti ensin ohjelman käyttöliittymä ilman oikeita toimintoja.  Tätä "protoa" voidaan sitten tutkia yhdessä asiakkaan kanssa ja päättää toimintojen loogisuudesta ja riittävyydestä.

Kun ohjelmaan on suunniteltu halutut toimenpiteet ja päätetty mitä tietorakenteita tarvitaan, on edessä työkalun valinta.  Nykypäivänä ei ole itsestään selvää, että valitaan työkaluksi jokin perinteinen ohjelmointikieli.  Vastakkain pitää asettaa erilaiset sovelluskehittimet, valmisohjelmat kuten tietokannat ja taulukkolaskennat, ehkä jopa tavallinen tekstinkäsittely sekä ohjelmointikielet.  Matemaattisissa ongelmissa jokin symbolisen tai numeerisen laskennan paketti saattaa olla soveltuva. 

Ratkaisu voi koostua myös useiden eri ohjelmien toimintojen yhdistelemisestä: CAD -ohjelmalla piirretään/digitoidaan kartan  pohjakuva, tietokantaohjelmalla pidetään kirjaa paikoista ja pienellä C/C++ tai Java-kielisellä ohjelmalla suoritetaan ne osat, joita CAD-ohjelmalla tai tietokantaohjelmalla ei voida suorittaa.

Joskus työkaluksi valitaan prototyyppiä varten jokin sovelluskehitin tai tietokantaohjelmisto.  Kun halutut toiminnot on perusteellisesti testattu ja tuotetta tarvitsee edelleen kehittää, voidaan ohjelmointi toteuttaa uudelleen vaikkapa Java-kielellä.  Prototyyppi on rinnalla toimivana ja uudessa ohjelmassa käytetään samoja tietoja ja toimintoja.

Mikäli työkalun valinnassa päädytään olio/lausekieleen (esim. C++ tai Java), ei pyörää kannata keksiä uudelleen.  Nelikulmioon nähden kolmikulmiossa on yksi poksaus vähemmän kierroksella, mutta kyllä silti ympyrä on paras.  Siis käytetään toisten kirjoittamia valmiita olioita ja/tai aliohjelmapaketteja "likaisessa" työssä.

Aina tietenkin puuttuu joitakin alemman tason palasia.  Nämä tietysti koodataan JA TESTATAAN ERILLISINÄ ennen varsinaiseen ohjelmaan liittämistä.

Siis itse koodaus on pienten aputyökalujen etsimistä, tekemistä, testaamista ja dokumentointia.  Lopullinen koodaus on näiden aputyökaluista muodostuvan palapelin yhteen liittäminen. 

Jo koodausvaiheessa kannattaa miettiä ongelman yleisiä ominaisuuksia.  Jos ollaan kirjoittamassa telinevoimistelun pistelaskua naisten sarjaan, niin koodissa ei mitenkään tulisi estää ohjelman käyttöä myös miesten sarjassa.  Siis telineiden nimet ja määrät pitäisi olla helposti muutettavissa.

Koodausta voidaan tehdä joko BOTTOM-UP periaatteella, jolloin ensin rakennetaan työkalut (=olioluokat/aliohjelmat) jotka sitten kasataan yhteen.  Toinen mahdollisuus on koodaus TOP-DOWN periaatteella, jolloin päätoiminnat kirjoitetaan ensin ja ala­toiminnoista tehdään aluksi tyhjiä laatikoita.  Myöhemmin valmiita ja testattuja alitoimintoja liitetään tähän runkoon.  Valitulla menetelmällä ei ole vaikutusta lopputulokseen ja joskus voikin olla hyvää vaihtelua siirtyä näpertelemään pikkuasioiden kimpussa isojen kokonaisuuksien sijasta tai päinvastoin.

Missään tapauksessa ohjelma ei synny siten kuin se kirjallisuudessa näyttää olevan: alkumäärittelyt, aliohjelmat ja päämoduuli.

Koodaajan on osattava hyvin käytettävä työkalu, esim. ohjelmointikieli.  Kuitenkin jonkin ohjelmointikielen hyvän osaamisen avulla on suhteellisen helppo kirjoittaa myös muunkielisiä ohjelmia.

Koodaus on pääosin tekstinkäsittelyä ja 10-sormijärjestelmä nopeuttaa koodin syntymistä oleellisesti.  Myös hyvä tekstinkäsittelytaito valmiiden palasten siirtelemisineen ja kopioimisineen helpottaa tehtävää.

Ohjelman testaus alkaa jo suunnitteluvaiheessa.  Valitut algoritmit ja toiminnot pitää pöytätestata teoriassa ennen niiden koodaamista.  Suunnitteluvaiheessa täytyy miettiä kaikki mahdolliset erikoistapaukset ja todeta algoritmin selviävän niistäkin tai ainakin määritellä miten erikoistapauksissa menetellään.  Testitapaukset kirjataan ylös myöhempää käyttöä varten.

Koodausvaiheessa kukin yksittäinen aliohjelma/luokka testataan kaikkine mahdollisine syötteineen pienellä testiohjelmalla. Aliohjelman kommentteihin voidaan kirjata suunnitteluvaiheessa todettu testiaineisto ja testausvaiheessa ruksataan testatut toiminnot ja erikoistapaukset. Tavan heikkous piilee kuitenkin siinä, että mikäli haluamme muuttaa nyt alkuperäistä koodia, meidän on mahdoton tietää vaikuttaako muutos johonkin toiseen ohjelmiston osa-alueeseen joka käyttää koodia hyväkseen. 

Nykyisin ratkaisuksi on kehitetty testausta automatisoivia työkaluja, kuten Javan käyttämä JUnit. Yksikkötestauksen idea on kirjoittaa jokaisen ohjelmiston osaan testikoodi, mikä voidaan ajaa keskitetysti vaikka koko ohjelmistolle kerralla.

Eräs yksikkötestausta hyödyntävä tekniikka on testivetoinen kehitys (TDD, test-driven development). Sen tarkoituksena on kirjoittaa koodi testattavaksi ja testit ennen varsinaisen ohjelmakoodin kirjoittamista. Tämän ehkä aluksi nurinkuriselta tuntuvalla ajatuksella on kuitenkin useita hyötyjä.  Kyse ei ole niinkään testaustyökalusta, vaan ohjelman suunnittelusta, josta syntyykin sivutuotteena valmiit testitapaukset.

Tällä kurssilla testaamiseen voi käyttää myös Jyväskylän yliopistossa kehitettyä ComTest työkalua. Työkalu helpottaa JUnit testien tekemistä ja sen avulla pystyy samalla luomaan myös kattavan JavaDoc dokumentaation.

Lopullisen ohjelman toimivuus riippuu hyvin paljon siitä, miten hyvistä palasista se on kasattu. 

Ennen virheiden löytämiseksi testiohjelmiin lisättiin tulostuslauseita.  Nykyisin tehokkaat debuggerit helpottavat testausta huomattavasti: ohjelman toimintaa voidaan seurata askel kerrallaan ja epäilyttävien muuttujien arvoja voidaan tarkistaa kesken suorituksen.  On myös mahdollista laittaa ohjelma pysähtymään jonkin muuttujan saadessa virheellisen arvon.

Testaus on vaihe, missä hyvä koneenkäyttörutiini ja epäluulo ovat suureksi avuksi.

Ketterien menetelmien tärkeimpiä osa-alueita on jatkuva vuorovaikutus asiakkaan kanssa. Aluksi tällä kurssilla asiakkaana toimii oppilas itse suunnitellessaan harjoitustyöohjelman toiminnot ja käyttötarkoituksen. Harjoitustyötä tehdään pienissä vaiheissa, eli iteraatioissa, joiden tarkoitus on pitää ohjelma jatkuvasti toimivana kokonaisuutena, mihin on helppo lisätä uusia ominaisuuksia yksi kerrallaan. Vaiheen päätettyä tehdään hyväksymistestaus, jossa työ esitellään asiakkaalle (ohjaajalle), jolta saa vinkkejä ja palautetta ohjelman toiminnan parantamiseksi.

Jokaisessa vaiheessa toteutetaan jokin ohjelman osa-alue tai parannellaan vanhaa. Tämä työ sisältää suunnittelun, testauksen, koodauksen ja dokumentoinnin.

Ketteriä menetelmiä käyttämällä ohjelman käyttöönottovaiheessa sen pitäisi olla testattu ja valmis. Tietysti julkaisuversioonkin pääsee lähes aina livahtamaan joitakin bugeja, mutta niiltä ei taitavinkaan ohjelmoija voi välttyä. Asiakas on lisäksi pidetty mukana koko prosessin ajan, eikä ikäviä yllätyksiä - joissa ohjelma ei olekaan toiminnallisuudeltaan sitä mitä on odotettu - pääse syntymään.

Jos kuitenkin ohjelmasta paljastuu virheitä tai puuttuvia toimintoja.  Virheet pitää korjata ja puuttuvat toiminnot mahdollisesti lisätä, jolloin ollaan jälleen ohjelmansuunnittelun alkuvaiheessa.  Hyvin suunniteltuun ohjelmaan saattaa olla helppo lisätä uusia toimintoja ja vastaavasti huonosti suunnitellussa saattavat jopa tietorakenteet mennä uusiksi.  Tosin tätäkään ei pidä pelätä, sillä yksinkertaisesti aina ei ole mahdollista ottaa etukäteen kaikkea huomioon.

Myös ohjelman alkuperäiset kirjoittajat ovat saattaneet häipyä ja mikäli kehitysprosessiin ei ole kiinnitetty tarpeellista huomiota, niin joku onneton kesätyöntekijä joutuu ensitöikseen paikkaamaan toisten huonosti dokumentoimaa sotkua.

Ohjelmointi ei yleensä ole yhden henkilön työtä.  Eri henkilöt voivat tehdä eri vaiheita ohjelmoinnissa.  Lähes aina tulee tilanne, missä jonkin toisen kirjoittamaa koodia joudutaan korjailemaan. 

Oli ohjelmaa tekemässä kuinka monta henkilöä tahansa (vaikka vain yksi), pitää ohjelmointi jakaa vaiheisiin.  Oikeaa ohjelmaa on mahdoton "nähdä" valmiina Java-kielisinä lauseina heti tehtävän määrityksen antamisen jälkeen.  Aloitteleva ohjelmoija kuitenkin haluaisi pystyä tähän (koska hän "näkee" määrityksestä: Kirjoita ohjelma joka tulostaa "Hello world", heti myös Java-kielisen toteutuksen).  Tämän takia ohjelmoinnin helpoin osa, eli koodaus koetaan ohjelmoinnin vaikeimmaksi osaksi - suunnittelu on unohtunut!

Valitulla ohjelmointikielellä ei ole suurtakaan merkitystä ohjelmoinnin toteuttamiseen.  Jokin kieli saattaa soveltua paremmin johonkin tehtävään, mutta pääosin BASIC, Fortran, Pascal, C, Modula-2, ADA jne. ovat samantyylisiä lausekieliä.  Samoin oliokielistä esimerkiksi C++, Java, C#, Delphi (Pascal) ja Python ovat hyvin lähellä toisiaan.  Kun yhden osaa, on toiseen siirtyminen jo helpompaa. 

Jos joku kuvittelee, ettei hänen tarvitse koskaan ohjelmoida C/C++ taiJava-kielellä, voi hän olla aivan oikeassakin.  Nykyisin kuitenkin jokaisessa tietokantaohjelmassa, taulukkolaskentaohjelmassa ja jopa tekstinkäsittelyohjelmissakin (vrt. esim. T_EX, joka on tosin ladontaohjelma) on omat ohjelmointikielensä.  Osaamalla jonkin ohjelmointikielen perusteet, voi saada paljon enemmän hyötyä käyttämästään valmisohjelmasta.  Ja joka väittää selviävänsä nykymaailmassa (ja sattuu lukemaan tätä monistetta) esimerkiksi ilman tekstinkäsittelyohjelmaa on suuri valehtelija!

 

 

Nyt tavuja taikomahan,

koodia kokoamahan?

Tuosta tokkopa tulisi

ohjelmaapa oivallista.

 

Ongelma jo täytyy olla

suunnitelma siivitellä

aikeet aina aatostella

toki tarpeet tarkastella.

 

Saatatko tuon jo sanoa

tieto kusta tarvitahan

ohjelman ositeltavan

jo bitteiksi pilkottavan.

 

Nyt liimaile liittymätä

sitä silmälle suotavaksi

käyttäjälle nähtäväksi

muille mutristeltavaksi.

 

Mitä tässä luvussa käsitellään?

•  tehtävän "analysointi"

•  ohjelman vaatimien aputiedostojen sisällön suunnittelu

•  ohjelman suunnittelu ohjelman tulosteiden avulla

•  suunnitelman korjaus

•  tarvittavien algoritmien hahmottaminen

•  relaatiotietomalli

Ohjelman suunnittelu aloitetaan aina tehtävän tarkastelulla.  Annettua tehtävää joudutaan usein huomattavasti tarkentamaan. 

Olkoon tehtävänä suunnitella kerhon jäsenrekisteri.  Onko kerho iso vai pieni?  Mitä tietoja jäsenistä tallennetaan?   Mitä ominaisuuksia rekisteriltä halutaan?

Mikäli sovitaan, että kerho on kohtuullisen pieni (esim. alle 500 jäsentä), ei meidän heti alkuun tarvitse miettiä parhaita mahdollisia hakualgoritmeja eikä tiedon tiivistämistä.

Mitä tietoja jäsenistä tarvitaan?

 

Mitä ominaisuuksia rekisteriltä halutaan?

On varsin selvää, ettei tätä nimenomaista tehtävää kannattaisi nykypäivänä lähteä itse ohjelmoimaan, vaan turvauduttaisiin tietokantaohjelmaan.  Joissakin erikoistapauksissa saatetaan vaatia ominaisuuksia, joita tietokantaohjelmasta ei saada. Tällöin työkaluksi valittaisiin lausekieli ja tietokantaohjelmiston  aliohjelmakirjasto, joka hoitelee varsinaiset tietokannan ylläpitoon yms. liittyvät toimenpiteet. 

Edellinen analyysi on kuitenkin tehtävä työkalusta riippumatta!  Esimerkin vuoksi jatkamme tehtävän tutkimista hieman pidemmälle tavoitteena ohjelmoida jäsenrekisteri jollakin lausekielellä.

Mikäli työkalun valinnassa on päädytty johonkin lausekieleen, on jossain vaiheessa päätettävä käytettävistä tietorakenteista.  Esimerkin tapauksessa meillä on selvästikin joukko yhden henkilön tietoja.  Mikäli yhden henkilön tietoa pidetään yhtenä yksikkönä (tietueena), on koko tietorakenne taulukko henkilöiden tiedoista.  Taulukko voidaan tarvittaessa toteuttaa myös lineaarisena listana tai jopa puurakenteena.  Mikäli kyseessä on pieni rekisteri, mahtuu koko tietorakenne ohjelman ajon aikana muistiin.  

Missä tiedot tallennetaan kun ohjelma ei ole käynnissä? Tietenkin levyllä tiedostona.  Minkä tyyppisenä tiedostona?  Tiedoston tyyppinä voisi olla binäärinen tiedosto alkioina henkilötietueet.  Tällaisen tiedoston käsittely hätätapauksessa on kuitenkin vaikeata.  Varmempi tapa on tallentaa tiedot tekstitiedostoksi, jota tarvittaessa voidaan käsitellä millä tahansa tekstinkäsittelyohjelmalla.  Tällöin on lisäksi usein mahdollista käsitellä tiedostoa taulukkolaskentaohjelmalla tai tietokantaohjelmalla ja näin joitakin harvinaisia toimintoja voidaan suorittaa rekisterille vaikkei niitä olisi alunperin edes älytty laittaa ohjelmaan mukaan.

Minkälainen tekstitiedosto?  Ehkäpä yhden henkilön tiedot yhdellä rivillä?  Miten yhden henkilön eri tiedot erotetaan toisistaan?  Mahdollisuuksia on lähinnä kaksi:  erotinmerkki tai tietty sarake.  Valitaan erotinmerkki.  Usein on mukavaa lisäksi laittaa joitakin huomautuksia eli kommentteja tiedostoon.  Siis tallennustiedoston muoto voisi olla vaikkapa seuraava:

 

Tällaisenaan tiedosto on varsin suttuinen luettavaksi.  Vaikka valitsimmekin erotinmerkin erottamaan tietoja toisistaan, voimme silti kirjoittaa vastaavat tiedot allekkain sopimalla, ettei loppuvälilyönneillä ole merkitystä.

 

Nyt tiedostoa on helpompi lukea ja tyhjien kenttien jättäminen ei ole vaikeaa.  Tiedosto vie kuitenkin levyltä enemmän tilaa kuin ensimmäinen versio, mutta sillä ei tietenkään nykyään ole mitään merkitystä.  Lisäksi yhden henkilön tiedot eivät mahdu kerralla näyttöön.  Onneksi kuitenkin lähes kaikki tekstieditorit suostuvat rullaamaan näyttöä myös sivusuunnassa.  Mikäli saman henkilön tietoja jaettaisiin eri riveille, tarvitsisi meidän valita vielä tietueen loppumerkki (nytkin se on valittu: rivinvaihto).

Jatkosuunnittelu on ehkä helpointa tehdä suunnittelemalla ohjelman toimintaa käyttöohjeen tai käyttöliittymän tavoin.

Vaikka nykyaikaisilla ohjelmointiympäristöillä käyttöliittymän piirtäminen on tottuneelle käyttäjälle todella nopeaa, niin ensikertalaisen on kuitenkin helpompaa nopeampaa toteuttaa alustava suunnittelu perinteisesti esimerkiksi kynällä ja paperilla.

Suunnittelussa toimitaan käyttäjän ja helppokäyttöisyyden (= myös nopea käyttö, ei aina välttämättä hiiri) ehdoilla. On myös huomioitava ohjelmoitava alusta ja siinä vakiintuneet tavat toteuttaa toimintoja.

Ohjelma käynnistetään klikkaamalla kerho.jar-ikonia tai antamalla komentoriviltä komento

 

Kun ohjelma käynnistyy, tulostuu näyttöön

 

Kerhon tiedot on tallennettu vaikkapa tiedostoon nimet.dat (hakemistoonkelmit).  Näin voimme ylläpitää samalla ohjelmalla useiden eri kerhojen tietoja.   Mitäpä jos tiedostoa ei ole?  Tällöin voi syynä olla kirjoitusvirhe tai se, ettei rekisteriä ole vielä edes aloitettu.  Miten ohjelman tulee tällöin menetellä? Mikäli käyttäjä antaa tiedoston nimen, jollaista ei tunneta, tulostuu näyttöön:

 

Tällöin käyttäjä voi aloittaa syöttämään uusia jäseniä tai jos kirjoitti nimen väärin, hän voi ottaa menusta Avaa-valinnan ja antaa uuden nimen

Edellä on edetty siihen saakka, kunnes ohjelmassa on päädytty pääikkunaan. 

 

Pääikkunassa on seuraava menurakenne.

 

Seuraavaksi voimme lähteä tarkastelemaan eri alakohtien toimintaa.

Pääikkunan vasemmassa reunassa näkyy Hakuehto. Tästä voi valita minkä kentän mukaan etsitään. Tämän jälkeen tekstikenttään voi syöttää hakuehdon ja listaan tulee vain ne jäsenet joille haku toteutuu. Hakutermi saa löytyä valitusta kentästä mistä kohti vaan. Esimerkiksi jos kirjoitetaan hakuehtoon s, niin haetaan kaikki jäsenet joiden nimessä on s jossakin kohti.

Löytyneet jäsenet lajitellaan valitun hakukentän perusteella.

Valittua jäsentä voidaan muokata menemällä tietoihin oikeaan kohtaan ja kirjoittamalla uusi arvo. Jos tietoon syötetään jotakin mikä ei kelpaa toimitaan seuraavasti.

 

Samalla virheellinen syöttökenttä menee punaiseksi.

Luo uuden tyhjän jäsenen.

Poistaa listasta valitun jäsenen. Varmistaa ennen poistoa.

Tulostaa hakuehdon täyttävät jäsenet erilliseen ikkunaan halutussa muodossa. Tässä "esikatselussa" voi vielä muuttaa tietoja ja sitten tulostaa paperille.

Ohjelman lopetuksessa tulee huolehtia siitä, että ohjelman aikana mahdollisesti rekisteriin tehdyt muutokset tulevat tallennetuiksi.   Tämä voidaan tehdä automaattisesti tai tallennus voidaan varmistaa käyttäjältä.  Automaattisen tallennuksen tapauksessa alkuperäinen tiedosto on ehkä syytä tallentaa eri nimelle. 

Näyttää selaimessa ohjelman käyttöohjeen

Näyttää ohjelmasta tietoja vähän samaan tapaan kuin aloitusikkunassakin.

Kun vaihe on valmis ja ohjelma täyttää sille asetetut vaatimukset se käydään läpi yhdessä asiakkaan ja tiimin kanssa, eli tässä tapauksessa jollakin kurssin ohjaajista. Usein tässä vaiheessa keksiikin työhön jotain parannuksia, mitä ei itse ole tullut ajatelleeksi. Viat yleensä korjataan seuraavaan vaiheeseen mennessä, mutta mikäli työ on jäänyt huomattavan keskeneräiseksi, niin kannattaa näyttää koko vaihe uudestaan. 

Ensimmäisessä vaiheessa tutkitaan siis kirjoitettua käyttöohjetta, tietorakennetta ja piirrettyjä kuvia, jotka muodostavat alustavan suunnitelman ohjelman toiminnallisuudesta.

Alussa tyypillisimmät viat liittyvät liian minimalistiseen dokumentaatioon. Dokumentaatiossa on hyvä pyrkiä täsmällisyyteen, sillä luotua tietoa hyödynnetään jatkuvasti projektin edetessä. Kaikki yleisimmät virheet johtuvat siitä, että yritetään oikaista asioissa, jotka vievät muutenkin vain murto-osan vaiheeseen käytetystä ajasta.

Tyypillistä on että mallitiedostot näyttävät jokseenkin tältä: 

 

Tiedoston sisällöstä saa nyt jonkinlaisen idean, mutta selkeyden vuoksi mallidataa tarvitsee useita rivejä ja sen tulisi koostua "oikeista" arvoista. Dokumentaatiota kirjoittaessa pieni ajan säästäminen kostautuu useasti projektin edetessä. Kun sisällön tekee nyt kunnolla, niin samaa dataa voi käyttää hyödyksi viidennessä vaiheessa tietorakennekuvaa piirrettäessä, sekä mallitiedostona ohjelmaa luotaessa.

Lisäksi kannattaa miettiä ohjelman käyttötarkoitusta. Olisi rasittavaa jos Kerho aina varmistaisi saako käyttäjän lisätä, koska virheellisesti luodun henkilön tietoja voi kuitenkin jälkikäteen muokata. Käyttäjälle näytettävät varmistusdialogit sopivat peruuttamattomien muutoksien yhteyteen, mutta väärässä paikassa käytettynä ne hidastavat käyttöä täysin turhaan.

Ennen harjoitustyön näyttämistä kannattaa aina käydä tarkistamassa kurssin wikistä malliharjoitustyö ja tyypilliset harjoitustyön viat, jolloin selviää turhalta korjaamiselta.

Nyt olemme selvillä ohjelman toiminnasta.  Edellisestä käyttöohjeesta voimme etsiä mitä työkaluja (aliohjelmia) tarvitsemme ohjelman toteutuksessa.  Ainakin seuraavat tulevat helposti mieleen:

1.  tiedoston lukeminen

2.  tiedoston tallentaminen

3.  henkilön tietojen kysyminen päätteeltä

4.  tiedoston lajittelu haluttuun järjestykseen

5.  tiedon etsiminen tiedostosta tietyllä hakuehdolla

6.  uuden henkilön lisääminen tiedostoon

7.  henkilön poistaminen tiedostosta

Mikäli tutkimme yo. palasia tarkemmin, tarvitsemme ehkä seuraavia pienempiä ohjelman palasia (apualiohjelmia):

1.    pitkän merkkijonon pilkkominen osamerkkijonoihin annetun merkin kohdalta

2.    loppuvälilyöntien poistaminen merkkijonosta

3.    isojen ja pienien kirjainten muuttaminen merkkijonossa esimerkiksi:

 

4.    hetun oikeellisuuden tarkistus

5.    ovatko merkkijonot "*aku*" ja "AKU ANKKA" samoja?

Seuraava vaihe olisi suunnitelman koodaaminen valitulle ohjelmointikielelle.  Voisimme kirjoittaa aluksi löytämiämme alimman tason aliohjelmia (BOTTOM-UP-suunnittelu) ja testata ne toimiviksi.  Voisimme myös kirjoittaa pääohjelman ja tyhjiä aliohjelmia testataksemme ohjelman rungon (TOP-DOWN).  Puuttuvien toimintojen kohdalla ohjelma voidaan laittaa sanomaan.

 

Emme kuitenkaan osaa vielä riittävästi ohjelmointikieltä, jotta voisimme aloittaa koodauksen.  Huomattakoon, ettei yllä olevassa suunnitelmassa ole missään kohti vedottu käytettävään ohjelmointikieleen.  Palaamme myöhemmin takaisin ohjelman osien koodaamiseen.

Vaikka sihteerimme ei juuri nyt huomannutkaan, saattaa hän tulevaisuudessa esimerkiksi kysyä miten rekisterillä pidettäisiin yllä tietoja jäsenten harrastuksista.  Mietitäänpä?

Ensin miten harrastukset muuttaisivat tiedostomuotoamme?

Eräs mahdollisuus olisi lisätä kunkin rivin loppuun jollakin erotinmerkillä harrastukset:

 

Ratkaisu toimisi tietyissä erityistapauksissa.  Ongelmia tulisi esimerkiksi jos pitäisi kuhunkin harrastukseen liittää esimerkiksi harrastuksen aloitusvuosi, viikoittain harrastukseen käytetty tuntimäärä jne.

Edellinen ongelma ratkeaisi esimerkiksi laittamalla henkilön tietojen rivin perään jollakin tavalla eroavia rivejä, joilla harrastuksen on lueteltu:

 

Ratkaisu olisi aivan hyvä ja tämän ratkaisun valitsemiseksi meidän ei tarvitsisi tehdä mitään muutoksia tiedostomuotoomme vielä tässä vaiheessa.

Huono puoli on kuitenkin se, että tämän muotoisen tiedoston siirrettävyys muihin järjestelmiin on varsin huono.

Suurin osa tämän hetken valmiista järjestelmistä käyttää relaatiotietokantamallia.  Tämä tarkoittaa sitä, että koko tietokanta koostuu pienistä tauluista, jossa kukin rivi (=tietue) on samaa muotoa.  Eri taulujen välillä tiedot yhdistetään yksikäsitteisten avainkenttien avulla.  Meidän esimerkissämme nimet.dat olisi yksi tällaisen taulu ja sosiaaliturvatunnus kelpaisi yhdistäväksi avaimeksi (relaatioksi).

Kuitenkin sosiaaliturvatunnus on varsin pitkä kirjoittaa ja välttämättä sitä ei saada kaikilta.  Jos tällainen pelko on olemassa, täytyy avain luoda itse.  Itse ohjelman käyttäjän ei tarvitse tietää mitään tästä uudesta muutoksesta, vaan ohjelma voi itse generoida avaimet ja käyttää niitä sisäisesti.

Valitaan vaikkapa juoksevasti generoituva numero. Jos jäseniä poistetaan jää ko. jäsenen numero vapaaksi eikä sitä yritetäkään enää käyttää.  Uuden jäsenen numero olisi sitten aina suurin jäsenen numero +1.

 

Harrastukset kirjoitetaan toiseen tiedostoon (hakemistoon kelmit), jossa tunnusnumerolla ilmaistaan kuka harrastaa mitäkin harrastusta.

 

Nyt esimerkiksi kysymykseen "Mitä Sepe Susi harrastaa" saataisiin vastus etsimällä ensin Sepe Suden tunnus (2) tiedostosta nimet.dat.  Sitten etsittäisiin ja tulostettaisiin kaikki rivit joissa tunnus on 2 tiedostosta harrastukset.dat.

Myös vastaus kysymykseen "Ketkä harrastavat laiskottelua" löytyisi suhteellisen helposti.

Tämä ratkaisu vaatii muutoksen tiedostomuotoomme jo suunnitelman tässä vaiheessa, mutta toisaalta mikäli ratkaisu valitaan, voidaan sen ansiosta lisätä jatkossa vastaavia "monimutkaisia" kenttiä rajattomasti tekemällä kullekin oma "taulu".

Valitsemmekin siis tämän ratkaisun, eli annamme kullekin jäsenelle tunnusnumeron heti alusta pitäen.  Itse ohjelman käyttösuunnitelmaan ei tässä vaiheessa tarvita muutoksia.

Kirjoita algoritmi joka relaatiomallin tapauksessa vastaa kysymykseen "Ketkä harrastavat harrastusta X".

 

Nykyisin on kovasti muotia, että jokainen ohjelma osaa lukea ja kirjoittaa XML-muotoista tiedostoa (Extensible Markup Language).  Meidän ohjelmamme tiedosto voisi olla vaikka seuraavan näköinen XML­-muotoisena:

 

Kuten edeltä nähdään, on XML varsin tuhlaileva tallennusmuoto.  Sen käyttöä puoltaa lähinnä sen standardinmukaisuus.  Tuon tiedoston voi lukea tulevaisuudessa vaikka millä ohjelmalla.  Haittapuolena on työläämpi lukeminen omassa ohjelmassa.  Tosin jos on tarkoitus selvitä vain ylläkuvatun mukaisesta tiedostosta, ei koodaus ole kovin paljon monimutkaisempaa kuin muidenkaan tiedostomuotojen kanssa.  Lisäksi esim. Java-kieleen löytyy useita XML-jäsentimiä valmiiksi käytettävinä luokkina.

 

Laske mikä edellä esitetyistä vaihtoehtoisista tiedostomuodoista on tilaa säästävin kun rivinvaihtomerkin lasketaan vievän yhden merkin verran tilaa ja välilyönnit "unohdetaan".   Laske karkeasti "merkkejä/jäsen".

Luultavammin nopein tapa käyttöliittymäsuunnittelijalle tai ohjelmoijalle on suunnitella graafinen käyttöliittymä kynän sijaan suoraan jollakin nykyaikaisella graafisella ohjelmointiympäristöllä. Tähän osaan sitten lisätään heti tai jälkeenpäin itse toiminnallisuus.  Tällaisia työkaluja on esimerkiksi Eclipse (vaatii WindowBuilder pluginin), NetBeans, Visual Studio, C++Builder,  Delphi ja myös muiden ohjelmointikielten resurssityökalut.

Ohjelma suunnitellaan nimenomaan "piirtämällä" käyttäjälle näkyvä käyttöliittymän osa. Tässä tilanteessa on mahdollista pitää jopa asiakas mukana, jolloin ohjelman vaatimukset ja suunnitelmat selkeytyvät molempiin suuntiin. Ohjelmasta saattaa puuttua jotain tärkeitä ominaisuuksia, se saattaa olla liian vaikea käyttää, eikä ole myöskään tavatonta että alustavasti ohjelmaan on suunniteltu jopa tarpeettomia osia. Tilanteessa kiteytyy pitkälti se miksi johdanto-osuudessa esitellyt ketterien menetelmien arvot ovat käytännössä niin toimivia.

Tyypillisesti käyttöliittymät koostuvat ns. komponenteista. Ohjelmointikielelle tehdyt valmiit käyttöliittymäkirjastot sisältävät joukon valmiita komponentteja, kuten ikkunoita, paneeleita, tai vaikkapa nappeja. Yleensä komponentit rakentuvat muutamasta erilaisesta tyypistä, joskin käytettyjen kirjastojen välillä saattaa olla jonkinlaisia eroja.

Ikkunat (Windows) ovat korkean tason komponentteja, jotka sisältävät muita komponentteja. Ohjelmassa on yleensä yksi pääikkuna, jolla tosin voi olla lapsia, eli toisia ikkunoita. Tyypillisesti tyhjä ikkuna sisältää yläpalkin, jossa on ikoni, tekstiä, ikkunan kokoon vaikuttavat pikanäppäimet ja rasti sulkemista varten. Ikkunan "tyhjä" osio koostuu säiliöstä.

Säiliöt (Containers) ovat ikkunoita matalamman tason komponentteja, joiden tehtävä on helpottaa muiden komponenttien ryhmittelyä erilaisten sijoitteluiden (layout) avulla. Monimutkaiset rakenteet saattavat vaatia useiden sisäkkäisten ja rinnakkaisten säiliöiden käyttöä.

Valikot (Menus) ovat tapa jäsennellä kontrolleja. Sijoitellaan usein ohjelman yläreunaan tai esimerkiksi hiiren oikean painikkeen taakse.

Kontrollit (Controls), kuten esimerkiksi napit, tekstikentät, muokattavat tekstikentät, edistymispalkit ja valintalaatikot, ovat tyypillisesti matalimman tason komponentteja, jotka toteuttavat jotakin täsmällistä toiminnallisuutta.

Kuva 3.1  Kerhon käyttöliittymässä käytettyjä Swing-komponentteja

 

Komponenttien sijoittelussa ja niiden toiminnassa kannattaa matkia paljon muita ohjelmia. Toki valikkopalkki on mahdollista laittaa vaikka ikkunan alareunaan, mutta samalla varmasti kasvattaa käyttäjän kynnystä oppia ohjelman sujuva käyttö. Kannattaa myös miettiä ohjelman käyttötarkoitusta ja alustaa. Hiiri ole välttämättä ainoa tapa käyttää graafistakaan ohjelmaa, joten usein tarvittavaan ohjelmaan on hyvä olla jonkinlaisia käyttöä nopeuttavia pikanäppäimiä. Toisaalta helppokäyttöisimmänkään tietokoneohjelman käytettävyys tuskin siirtyy sellaisenaan kännykälle.

On kuitenkin selvää, ettei valmis kirjasto voi tarjota suoraan kaikkea tarpeellista. Tähän on käytännössä kolme erilaista lähestymistapaa. Ensimmäinen - yleensä tarpeettoman työläs - ratkaisu on luoda tarvittavan toiminnallisuuden tarjoavat osa itse. Tällaisen komponentin pitää täyttää tietty määrä sille asetettuja vaatimuksia, jonka jälkeen se on käytettävissä käyttöliittymässä. Käytännöllisempää kuin tyhjästä aloittaminen usein onkin ylikirjoittaa ja laajentaa haluttu toiminnallisuus jo valmiista komponentista.

Ohjelmoinnissa hyvä nyrkkisääntö on, että samaa koodia ei kannata kirjoittaa kahdesti, vaan silloin se tulee refaktoroida esimerkiksi uuteen funktioon. Sama periaate toimii käyttöliittymien kohdalla. Kerho-ohjelmasta huomaamme, että jäsenten tiedot syötetään kenttiin, joissa vasemmalla puolella on tekstiä ja oikealla syötekenttä. Tällöinhän olisi kätevää, jos voisimme yhdistää nämä kaksi komponenttia yhdeksi kokonaisuudeksi. Tätä ratkaisua kutsutaan koostamiseksi. Käyttäessämme Javan Swing kirjastoa, voimme luoda esimerkiksi EditPanel -komponentin, jolla on vaihdettava tekstikenttä (JLabel) ja kirjoituskenttä (JTextField).

Kuva 3.2  Koostettu komponentti EditPanel

 

Kuva 3.3  EditPanel -komponentteja allekkain

 

Käytettävästä ympäristöstä ja ohjelmointikielestä riippumatta käyttöliittymien suunnittelutyökalut muistuttavat hyvin paljon toisiaan. Esimerkkinä on käytetty Eclipseen asennettua WindowBuilder Pro -laajennusta Javan Swing-ympäristössä. Toiminnallisuuteen ei kuitenkaan syvennytä kuin pinnallisesti, koska työkalujen kehittyminen on nopeaa ja on mahdollista, että seuraavan version kohdalla tämäkin moniste on jo vanhentunut.

Kuva 3.4  Eclipse ja WindowBuilder Pro -plugin

 

1.    Komponentit ja niiden sisäkkäinen rakenne (Structure). Kannattaa myös huomata että kaikki esikatselussa näkyvä, pääikkunaa myöten, on oma komponenttinsa.

2.    Ominaisuudet (Properties). Komponentin voi aktivoidaa joko rakenne- tai esikatseluikkunasta, jolloin sen ominaisuuksia voi muuttaa. Erilaisilla komponenteilla on toisistaan eroavat ominaisuudet. Tällaisia ominaisuuksia ovat esimerkiksi napissa lukeva teksti tai sen koko.

3.    Käytettävissä olevat työkalut ja komponentit (Palette). Kokoelma valmiita komponentteja, joita pystyy ottamaan käyttöön vetämällä halutun joko rakenne- tai esikatseluikkunaan

4.    Esikatselu (Preview).

 

Ohjelmointikieli ja siinä käytetyt kirjastot kyllä tuovat itse ohjelmakoodiin suuriakin eroja. Nykyään monet kirjastot käyttävät hyväkseen XML-tiedostoja, joihin tallennetaan ulkoasun ja komponenttien ominaisuudet samaan tapaan kuin html-tiedostoihin. Kurssilla käytetty Javan Swing-kirjasto ei kuitenkaan tätä mahdollisuutta ainakaan vielä tarjoa. XML:n käytöllä saavutetaan ainakin teoriassa parempi siirrettävyys eri järjestelmien ja laitteiden välillä. Eri tekniikoiden välillä ei kuitenkaan ole mitään yhtenäistä standardia, mutta XML-pohjaiset toteutukset on kuitenkin helpompi tulkita.

Käyttöliittymien toiminnallisuus toteutetaan tapahtumien (event) avulla. Hiiren oikea näppäin halutun komponentin päällä avaa valikon josta voi tutkia erilaisista käyttäjän toimista aktivoituvia tapahtumia. Oikean toiminnallisuuden kanssa pitää hieman miettiä. Miten painikkeen (Button) painaminen tapahtuu? Nopeasti voisi ajatella että kun hiiren vie painikkeen päälle ja painaa (MousePressed), niin on intuitiivista että seuraa tapahtuma. Näinhän ei kuitenkaan ole, vaan yleensä tapahtuma seuraa vasta sitten kun hiiri on painettu alas ja päästetty ylös (MouseClicked). Oikea tapahtuma painikkeelle on kuitenkin ActionPerformed, joka huomio myös näppäimistön avulla tehdyt valinnat.

 

Kuva 3.5 WindowBuilder Pro ja valikko tapahtumien hallintaan

 

Tapahtuman luominen lisää seuraavat rivit koodiin. Ohjelma lisää painikkeelle uuden tapahtumakuuntelijan. Ohjelmakoodin toiminnan ymmärtäminen vaatii kuitenkin suhteellisen edistynyttä olio-ohjelmoinnin tietämystä, joten ei kannata säikähtää vaikka tekninen toteutus ei täysin aukeaisikaan.

 

Lohkoon jossa kutsumme tallenna()-metodia olisimme tietysti voineet kirjoittaa halutun toiminnallisuuden suoraankin. Metodikutsu on kuitenkin parempi tapa, koska koodista tulee näin paremmin jäsenneltyä ja tulkittavaa. On myös mahdollista että tarvitsemme samaa toiminnallisuutta useampaan kertaan. Tällöin voisimme laittaa esimerkiksi CTRL+S pikanäppäinyhdistelmän osoittamaan samaan metodiin.

Tässä vaiheessa ohjelmamme ei osaa kuitenkaan vielä tallentaa mitään, joten metodin tehtävä on vain kertoa se erillisessä dialog-ikkunassa.

 

 

 

 

Kirjettä jos kirjoittelet,

ulkomaille viestittelet,

tokko Ruohtia viskomassa,

turhaan sanoja kiskomassa?

 

Aloittanet aatoksilla,

kotokielellä pohtimalla,

viestin vääntöö valmistellen,

siistimiseksi sisällön.

 

Sama kaava koodatessa

kääntäjätä käskiessä

kotokieltä alkuun käytä

vasta sitten ruutuun täytä.

 

Algoritmit alkuun teeppä

koneen kimppuun vasta meeppä

kun selvillä on tarkka kaava

jopa kääntyy Cee ja Jaava.

 

Mitä tässä luvussa käsitellään?

•  mikä on algoritmi

•  vertailu ja lajittelu

•  algoritmin kompleksisuus

•  alkion etsiminen joukosta

 

Kun ohjelman suunnittelu on edennyt siihen pisteeseen, että tarvitaan yksityiskohtaisia algoritmeja, meneekin jo monella sormi suuhun.

Vaikeudet johtuvat taas liian hankalasta ajattelutavasta ja siitä, että algoritmi yritetään nähdä osana koko ohjelmaa.  Tästä ajattelutavasta on luovuttava ja osattava määritellä tarvittava algoritmi omana kokonaisuutenaan, jota suunniteltaessa sitten unohdetaan kaikki muu.

Algoritmi on se joukko toimenpiteitä, joilla annettu tehtävä saadaan suoritettua.  Mieti esimerkiksi miten selostat kaverillesi ohjeet juna-asemalta opiskeluboxiisi.

Voit tietysti antaa ohjeet myös muodossa "Tule osoitteeseen Ohjelmoijankuja 17 B 5".  Tämäkin on varsin hyvä algoritmi.  Kaverin vain oletetaan nyt osaavan enemmän.  Kaverin oletetaan osaavan etsiä katuluettelosta kadun paikka ja keksivän itse menetelmän tulla asemalta sinne.

Toisaalta kaverisi saattaa hypätä taksiin ja sanoa kuskille osoitteen.  Tämä on hyvä ja helppo algoritmi, mutta ehkä liian kallis opintovelkaiselle opiskelijalle.  Mikäli algoritmia tarvitaan useasti, voidaan sitä myöhemmin parantaa tyyliin:

 

Tarkennettu algoritmi voisi olla myös seuraavanlainen:

 

Edellä eri kohdat eivät ole toisiaan poissulkevia.  Kello voi olla 9 ja rahaakin voi olla, mutta siitä huolimatta halutaan kävellä.  Hyvässä algoritmissa ei saa olla tällaisia epätäsmällisyyksiä, vaan ohjelmoijan tulee etukäteen jo päättää mitä missäkin tapauksessa tehdään.  Esimerkiksi:

 

Tässäkin algoritmissa jää vielä kaverillekin tehtävää:  Miten kävellään?  Miten astutaan bussiin jne..

No tätä ei kaverille ehkä enää selostetakaan.  Lapsille nämä asiat on aikanaan opetettu ja myöhemmin ne kuitataan yhdellä tai kahdella sanalla.  Sama pätee ohjelmoinnissakin.  Kerran tehtyä ei joka kerran pureksita uudelleen (vrt. aliohjelma)! 

Yritä kirjoittaa ohjeet siitä miten kävellään.

 

Kirjoita kaverillesi kävelyohjeet (missä käännytään, ei miten kävellään) rautatieasemalta asunnollesi.

 

Kerhon jäsenrekisteriä suunniteltaessa tulee jossakin kohtaa vastaan tilanne, jossa nimet tai osoitteet pitää pystyä lajittelemaan jollakin tavalla.

Jos osaamme lajitella numeroita, niin osaammeko lajitella nimiä?  Vastaus on KYLLÄ.  Mikä numeroiden lajittelussa on oleellista?  Oleellista on tietää onko numero A pienempi kuin numero B.  Miten tämä sitten soveltuu nimille?  Jos osaamme päättää onko nimi A aakkosissa ennen kuin nimi B, on ongelma ratkaistu.

Verrataanpa erilaisia nimiä:

 

B on ensin aakkosissa.  Miksi?  Koska B:n ensimmäinen kirjain (A) on ennen nimen A ensimmäistä kirjainta (K).

 

Nytkin B on ensin.  Siis miten vertaamme kahta nimeä?

 

Siinä meillä on algoritmi joka on varsin selvä.  Jos algoritmi haluttaisiin vielä kirjoittaa "lausekieliseen" muotoon, niin se olisi suurin piirtein seuraavanlainen:

 

Tähän vielä pieni "viilaus enemmän strukturoidummaksi", niin meillä olisikin valmis (ali)ohjelma nimien vertaamiseksi.

Vaikka esitimmekin algoritmin "lausekielisenä" kohdittain numeroituna, ei koskaan pidä unohtaa sitä ennen ollutta sanallista versiota, joka on selkeämpi kuvaus siitä ideasta, mitä tehdään!

Siis kirjoita aina ensin sanallinen kuvaava kuvaus algoritmista ja vasta sitten sen yksityiskohtainen "lausekielinen" versio!

Näin ollen on aivan yksi lysti opettelemmeko järjestämään nimiä vai numeroita.  Siksi paneudummekin seuraavassa numeroiden järjestämiseen.  Kuulostaako vaikealta?

Otapa käteesi korttipakka ja ota sieltä esiin vaikkapa vain kaikki padat.  Nyt sinulla on joukko "numeroita" (A=14, K=13, Q=12, J=11), yhteensä 13 kappaletta.  Sekoita kortit!  Yritä järjestää kortit suuruusjärjestykseen siten, ettet tarvitse pöytätilaa kuin yhden kortin verran, loput kortit pidät kädessäsi.

Millaisen algoritmin saat?  Ehkäpä seuraavan (insertion sort):

 

"Lausekielisenä":

 

Algoritmisi voi olla myös seuraava (selection sort):

 

Eli "lausekielisenä":

 

Mitä muita mahdollisia "lajittelumenetelmiä" keksit?

 

Siinä eräitä ratkaisuja tähän "hirveän vaikeaan" ongelmaan.  Ratkaisuissa on tiettyjä huonoja puolia, mutta ratkaisut ovat todella yksinkertaisia ja jokaisen itse keksittävissä. 

Mikäli kahden kortin vertaaminen lasketaan yhdeksi "operaatioksi", niin kuinka monta "operaatiota" joudumme tekemään, jotta pakka on lajiteltu Selection Sortilla?

 

Edellisen tehtävän vastausta sanotaan algoritmin kompleksisuudeksi.

Edellinen algoritmi (selection sort) toimi siten, että kortit jäivät pöydälle suurin päällimmäiseksi.  Miten algoritmia pitää muuttaa, jotta pienin saataisiin päällimmäiseksi?

 

Ei siis ole suurtakaan väliä pitääkö lajitella nouseva vai laskeva järjestys!

Kokeillaanpa vielä erästä algoritmia:  Sotke kortit kädessäsi uudelleen.

Bubble sort:

 

Tuleeko pakka järjestykseen tällä algoritmilla?  Voidaanko algoritmia nopeuttaa mitenkään?  Kirjoita algoritmista "lausekielinen" versio.

 

Kirjoita nyt joukko pahvilappuja, joissa kussakin on henkilön nimi, osoite ja puhelinnumero.

     

Sekoita laput ja kokeile toimiiko edelliset algoritmit mikäli laput järjestetään nimien mukaan.  Ai tyhmä ehdotus!  Tässä se onkin ohjelmoinnin vaikeus.  Asiat ovat yksinkertaisia!  Eiväthän ne osoitteet siellä lajittelua sotke. 

Mikäli laput järjestetään nimen mukaan, sanotaan nimen olevan lajitteluavaimena.  Lajitteluavaimeksi voitaisiin valita myös osoite tai puhelinnumero. Mikäli kahdella henkilöllä olisi sama nimi, voitaisiin nämä kaksi järjestää osoitteen perusteella.  Tällöin lajitteluavain muodostuisi merkkijonosta johon olisi yhdistettynä nimi ja osoite.

Kaikki edelliset algoritmit ovat kompleksisuudeltaan normaalitapauksessa samanlaisia.

Mikä edellisistä algoritmeista loppuu nopeasti, mikäli kortit jo olivat järjestyksessä?

 

Ohjelman toimintaan saattamisen kannalta olisi riittävää löytää jokin toimiva algoritmi.  Myöhemmin, mikäli ohjelman toiminta todetaan hitaaksi ko. algoritmin kohdalta, voidaan algoritmia yrittää tehostaa.  Lajittelussa tehostus saattaisi olla vaikkapa QuickSort (mukana mm. C-kielen standardikirjastossa).

Jos algoritmin kompleksisuus on esimerkiksi 2n²+n, sanotaan että kompleksisuus on O(n²), eli usein kiinnostaa vain kompleksisuuden suurin "potenssi".  QuickSortin keskimääräinen kompleksisuus on O(n log₂n).  On olemassa myös erikoistapauksissa toimivia lajitteluja, joissa kompleksisuus on O(n).  Piirrä kuva jossa on Selection Sortin, QuickSortin ja lineaarisen lajittelun käyttämä "aika" piirrettynä lajiteltavien alkioiden (n=10,100,1000,10000,1000000) funktiona.

Tutki kumpiko on työmäärältään edullisempaa jos järjestettyyn taulukkoon tulee lisättäväksi suuri määrä uusia alkiota

1)    lisätä alkio aina taulukkoon oikealle paikalleen

2)    lisätä alkio aina taulukon loppuun ja kun kaikki alkiot on lisätty, niin lajitella taulukko

 

Edellisissä lajittelualgoritmeissa oli vielä muutamia aukkopaikkoja!  Etsi pienin?  Laita oikealle paikalleen?

Miten kädessä olevista korteista voidaan etsiä pienin.  Yksi mahdollisuus on kuljettaa "pienin ehdokasta" läpi koko pakan.  Mikäli matkan varrelta löytyy parempi ehdokas, otetaan tämä tilalle.  Edellä mainittu kuplalajittelu korjattuna perustuu nimenomaan tähän ideaan.

Entä jos kädessä olevien korttien järjestystä ei haluta muuttaa?  Voisimme menetellä esimerkiksi seuraavasti (alkuarvaus ja arvauksen korjaaminen):

 

Miten kortti sijoitetaan paikalleen jo lajiteltuun kasaan? Esimerkiksi seuraavasti:

 

Usein tulee vastaan myös tilanne, jossa tietyn henkilön tiedot pitäisi hakea esimerkiksi nimen mukaan.  Mikäli valittu tietorakenne on järjestetty nimen mukaan, voidaan hakemisessa käyttää vaikkapa puolitushakua.

Nimen hakeminen ei taas poikenne kortin etsimisestä järjestetystä korttipakasta vai mitä?

 Kun kortit ovat järjestämättä, niin miten löydät haluamasi kortin?

 

Algoritmi on OK 13 kortille, mutta kokeilepa Äystön etsimistä puhelinluettelosta tällä algoritmilla (muista lukea jokainen nimi ennen Äystöä)!

Mikäli 13 korttiasi on järjestyksessä ja sinun pitäisi mahdollisimman vähällä pläräämisellä löytää vaikkapa pata 4, niin miten voisit menetellä?

 

Vaikuttaa tyhmältä 13 kortille, mutta kokeilepa 1000 kortilla!  Tai kokeile nyt etsiä ÄYSTÖÄ puhelinluettelosta tällä algoritmilla.

Kirjoita puolitushausta kunnon "lausekielinen versio" kun meillä on sivunumeroitu kirja, jonka kullakin sivulla on täsmälleen yhden henkilön tiedot.  Sivunumeroita kirjassa on N-kappaletta. Aloitat sivuista S1=0 ja S2=N+1.  Miten jatkat mikäli pitää etsiä nimi NIMI?

Mikä on puolitushaun kompleksisuus?

Tätä on ohjelmointi!  Kykyä (ja rohkeutta) sanoa selvät asiat täsmällisesti.  Jossain vaiheessa vaihdamme vain täsmällisyyden astetta ja "lausekielen" sijasta siirrymme käyttämään oikeata lausekieltä, esim. Java-kieltä.  Nämä omatekoiset algoritmit kannattaa kuitenkin säilyttää ja kirjata näkyviin todellisen ohjelman kommentteihin.  Arviot algoritmin nopeudesta kannattaa myös laittaa kommentteihin, jotta jälkeenpäin on helpompi etsiä jo tekovaiheessa hitaaksi epäiltyjä kohtia.  Miksi jättää seuraavalle lukijalle sama tehtävä ihmeteltäväksi, jos olemme sen toteutuksen jo jonnekin kirjanneet.

Algoritmit kannattaa testata huolellisesti jossain tutussa ympäristössä.  Hyvin moni ohjelmointiongelma vektoreiden (=taulukko, =kasa kortteja, =ruutupaperi, =sivunumeroitu kirja jne.) kanssa samaistuu johonkin jokapäiväiseen ilmiöön.  Kuten etsiminen puhelinluettelosta, korttipakan järjestäminen jne.  Yritä etsiä näitä yhteyksiä ja kokeile ensin ratkaista ongelma tällä tavoin.  Siirrä ratkaisu sitten "lausekielelle" ja lopulta ohjelmointikielelle.

Äläkä yritä liikaa, vaan jaa aina ongelma pienempiin osiin, kunnes tulee vastaan sen kokoisia osaongelmia, jotka osataan ratkaista!  Tällaista osaongelman ratkaisijaa sanotaan ohjelmointikielessä aliohjelmaksi.   

Kun osaongelma on ratkaistu, unohda se miten sen ratkaisija toimii ja käsittele ratkaisijaa vain yhtenä yksinkertaisena toimenpiteenä (vrt. aikaisempi kävelyesimerkki).  Tämä on myös eräs ohjelmoinnin "vaikeus".  Kirjoittaja haluaa nähdä kaikkien osien toiminnan yhtäaikaisesti.  Tämä on kuitenkin mahdotonta.  Siis kun jokin osa tekee hommansa, niin tehköön se sen miten tahansa. 

Huono on johtaja joka kyttää koko ajan alaisiaan, eikä luota siihen, että nämä tekevät heille annetun tehtävän.  Tässä mielessä ohjelmointia voisi verrata yrityksen johtamiseen:  Johtaja jakaa koko yrityksen pyörittämisessä tarvittavia tehtäviä alaisilleen (aliohjelmille).  Nämä saattavat edelleen jakaa joitakin osatehtäviä omille alaisilleen (aliohjelma kutsuu toista aliohjelmaa) jne.  Johtaja (=ohjelmoija ja pääohjelma) kokoaa alaisten tekemän työn toimivaksi kokonaisuudeksi ja firma tuottaa.

Kirjoita algoritmi polkupyörän kumin paikkaamiseksi.

Kirjoita algoritmi sunnuntai-illan viettoa varten (muista että ohjelmoinnin demot on maanantaina).

Kirjoita algoritmi 10 ei-alimittaisen kalan onkimiseksi mato-ongella.

Kirjoita algoritmi pöydälle levitetyn 13 kortin kääntämiseksi päinvastaiseen järjestykseen.

 

 

Tarvitaan nyt silmukoita,

kaiken maailman taulukoita,

eri ehtoja kummastella,

aliohjelmia aavistella.

 

Mitä tässä luvussa käsitellään?

•  silmukat ja valintalauseet

•  totuustaulut

•  pöytätesti

•  muuttujat

•  taulukot

•  osoittimet

 

Vaikka jatkossa keskitymmekin oliopohjaiseen ohjelmointiin, tarvitaan yksittäisen olion metodin toteutuksessa algoritmeja.  Riippumatta käytettävästä ohjelmointikielestä, tarvitaan algoritmeissa aina tiettyjä samantyyppisiä rakenteita.

Käsittelemme seuraavassa tyypilliset rakenteet nopeasti lävitse.  Tarvitsisimme asioille enemmänkin aikaa, mutta otamme asiat tarkemmin esille käyttämämme ohjelmointikielen opiskelun yhteydessä.  Lukijan on kuitenkin asioita tarkennettaessa syytä muistaa, ettei rakenteet ole mitenkään sidottu ohjelmointikieleen.  Vaikka ne näyttäisivät kielestä täysin puuttuvankin (esim. assembler), voidaan ne kuitenkin lähes aina toteuttaa.

Triviaaleja algoritmeja lukuun ottamatta algoritminen suoritus tarvitsee ehdollisia toteutuksia:

 

Ehtolauseita voi ehtoon tulla useampiakin ja tällöin on syytä olla tarkkana sen kanssa, mihin ehtoon mahdollinen muuten-osa liittyy:

 

Kuva 4.1 Ehtolauseet

 

Jos sinulla on muuttujassa t tunnit ja muuttujassa m minuutit, niin kirjoita algoritmi miten lisäät n minuuttia kellonaikaan t:m.

Kirjoita algoritmi g-painoisen kirjeen postimaksun määräämiseksi (saat keksiä hinnaston itse).

Usein ehtoja kasaantuu niin paljon, että peräkkäiset ja sisäkkäiset ehtolauseet muodostavat varsin sekavan kokonaisuuden.  Tällöin voi olla helpompi käyttää valintalausetta:

Kuva 4.2 switch-valintalause

 

Mieti kuinka valintalauseen logiikka korvattaisiin ehtolauseiden avulla.

 

Hyvin usein algoritmi tarvitsee toistoa: Esimerkiksi ohjeet (vuokaavio) hiekkarannalla toimimiseksi jos nenä näyttää merelle päin:

Kuva 4.3 do-silmukka ja do-while-silmukka

Ehtolause voi olla silmukan alussa, tällöin on mahdollista, ettei silmukan runkoa tehdä yhtään kertaa.  Ehto voi olla myös silmukan jälkeen, jolloin silmukan runko tehdään vähintään yhden kerran.  Joissakin kielissä on lisäksi mahdollisuus silmukan rungon keskeltä poistuminen.

Silmukoihin liittyy aina ohjelmoinnin eräs klassisimmista vaaroista: päättymätön silmukka!  Tämän takia silmukoita tulee käsitellä todella huolella.  Eräs oleellinen asia on aina muistaa suorittaa silmukan rungossa jokin silmukan lopetusehtoon vaikuttava toimenpide.  Mitä tapahtuu muuten?

Myös silmukan suorituskertojen lukumäärän kanssa tulee olla tarkkana.  Silmukka tulee helposti suoritettua yhden kerran liikaa tai yhden kerran liian vähän.

Mitä eroa on kahdella edellä esitetyllä "uimaan-meno" -algoritmilla?  Mitä ehtoja algoritmiin voisi vielä lisätä?

Kirjoita algoritmi lukujen 1-100 yhteenlaskemiseksi sekä do-while- että while -silmukan avulla.

 

Algoritmeissa tarvitaan usein muuttujia. 

 

Yksinkertaisessa tapauksessa muuttuja voi olla yksinkertaista tyyppiä kuten kellonaika (jos ilmaistu minuutteina), rahasumma jne.

Yksinkertainen luvun jaollisuuden testausalgoritmi voisi olla vaikkapa seuraavanlainen: 

Piirrä jaollisuuden testausalgoritmista vuokaavio.

 

Hyvin usein algoritmi kannattaa pöytätestata.  Pöytätesti alkaa kirjoittamalla sarakkeiksi kaikki algoritmissa esiintyvät muuttujat.  Muuttujiksi voidaan kirjoittaa myös algoritmissa esiintyviä ehtoja.  Tällainen muuttuja voi saada arvon kyllä tai ei.  Pöytätestin riveiksi kirjoitetaan algoritmin eteneminen vaiheittain.  Sarakkeisiin muuttujille kirjoitetaan uusia arvoja vain niiden muuttuessa.

Testataan esimerkiksi edellisen esimerkin algoritmi:

askel	Luku	Jakaja	Kasvatus	Luku/Jakaja	Jako tasan?	Jakaja<Luku/2?	Tulostus
0	25	2	1
1				12.500	ei
2		3
3			2
4						3<12.5
1				8.333	ei
2		5
3			2
4						5<12.5
1				5.000	kyllä		Jaollinen 5:llä

 

askel	Luku	Jakaja	Kasvatus	Luku/Jakaja	Jako tasan?	Jakaja<Luku/2?	Tulostus
0	23	2	1
1				11.500	ei
2		3
3			2
4						3<11.5
1				7.667	ei
2		5
3			2
4						5<11.5
1				4.600	ei
2		7
3			2
4						7<11.5
1				3.286	ei
2		9
3			2
4						9<11.5
1				2.556	ei
2		11
3			2
4						11<11.5
1				2.091	ei
2		13
3			2
4						13>11.5	Alkuluku

 

Usein pöytätesti antaa hyviä vinkkejä myös algoritmin jatkokehittelylle.  Käytännön työssä osa pöytätestistä voidaan suorittaa debuggereiden avulla.  Joskus kuitenkin voi olla niin paljon esitietoa algoritmille, että tarvittavan testiohjelman rakentaminen voi olla työlästä.  Pöytätestihän voidaan aloittaa minkälaisesta alkutilasta tahansa.  Samoin yksi pöytätestin etuja on siitä jäävä historia.  Usein debuggerit näyttävät vain yhden ajanhetken tilanteen, siis yhden pöytätestin rivin kerrallaan.

Tarvitsisimmeko algoritmin kohtaa 4 lainkaan?  Voitaisiinko algoritmin lopetus hoitaa muuten?

Pöytätestaa edellinen algoritmi kun syöttönä on luku 121.

Pöytätestaa molemmat Ynnää luvut 1-100 -algoritmisi versiona Ynnää luvut 1-6.

 

Tutkikaamme aikaisempia korttipakkaesimerkkejämme!  Nyt tietorakenteeksi ei enää riitäkään pelkkä yksi muuttuja.  Mikäli pakasta on otettu esiin pelkät padat, tarvitsisimme 13 muuttujaa.  Näiden kunkin nimeäminen erikseen olisi varsin työlästä. 

Tarvitsemme siis jonkin muun tietorakenteen.  Mahdollisuuksia on useita: listat, jonot, pinot ja taulukot.  Ohjelmoinnin alkuvaiheessa taulukot ovat tietorakenteista helpoimpia, joten keskitymme niihin aluksi.

Varataan pöydältä tilaa leveyssuunnassa 13 kortille.  Varattua tilaa voimme nimittää taulukoksi tai vektoriksi.  Taulukon yksi alkio on yhdelle kortille varattu paikka.  Taulukon yhden alkion sisältö on se kortti, joka on siinä paikassa. 

Mikäli numeroimme varatut paikat vaikkapa 0:sta alkaen vasemmalta oikealle, on meidän korteillamme osoitteet 0-12:

 Nyt voimme käsitellä yksittäisiä kortteja aivan kuin ne olisivat yksittäisiä muuttujia.  Viittaamme tiettyyn korttipaikkaan (taulukon alkioon) sen indeksillä (olkoon taulukon nimi kortit):

 

Minkälaisia algoritmeja tulee vastaan taulukoita käsiteltäessä?  Esim. ♠9:n siirtäminen taulukon viimeiseksi vaatisi ♠4:en siirtämistä paikkaan 5. ♠6:en siirtämistä paikkaan 6, ♠Q:n siirtämistä paikkaan 7 jne.  Näin loppuun saataisiin raivatuksi paikka ♠9:lle.

Lajittelun ilman valtaisaa korttien siirtelyä voisimme hoitaa seuraavasti:

 

Sovitaan, että ässä=1.  Nyt pienimmän kortin etsimisalgoritmi voisi olla seuraava:

 

Voisimme vielä pöytätestata algoritmin:

pien.

Kortit

[tutki]<

tutki<

askel

paikka

tutki

0

1

2

3

4

5

6

7

8

9

10

11

12

[pp]

suur.ind

0

0

0

♠7

♠3

♠K

♠2

♠5

♠9

♠4

♠6

♠Q

♠10

♠J

♠A

♠8

1

⇧t

7<7 ei

2&3

1

juu

1

1

⇧

t

3<7 juu

2&3

2

juu

1

⇧

t

K<3 ei

2&3

3

juu

1

3

⇧

t

2<3 juu

2&3

4

juu

1

⇧

t

5<2 ei

2&3

5

juu

1

⇧

t

9<2 ei

2&3

6

juu

1

⇧

t

4<2 ei

2&3

7

juu

1

⇧

t

6<2 ei

2&3

8

juu

1

⇧

t

Q<2 ei

2&3

9

juu

1

⇧

t

10<2 ei

2&3

10

juu

1

⇧

t

J<2 ei

2&3

11

juu

1

11

⇧

t

A<2 juu

2&3

12

juu

1

⇧

t

8<A ei

2&3

13

ei

 

Oletetaan, että pienimmän etsimisalgoritmi toimii.  Pöytätestaa edellä esitelty lajittelualgoritmi edellisen pöytätestin mukaisella korttien järjestyksellä.

 

Onko tämä insertion sort?  Missä on lajiteltujen kasa ja missä lajittelemattomien?

Kirjoita algoritmi kuvakorttien poistamiseksi taulukosta käyttäen indeksejä.

 

 Edellisessä pöytätestissä merkitsimme pienen merkin niiden korttien kohdalle, joita kunakin hetkenä tutkimme.  Kun tutkimme esimerkiksi paikoissa 3 ja 10 olevia kortteja (P2 ja PJ) voisimme sanoa, että muuttuja pien.paikka osoitti korttiin pata 2 ja muuttuja tutki korttiin pata jätkä.  Näin ollen voisimme oikeastaan sanoa, että (indeksi)muuttujat pien.paikka ja tutki ovat osoittimia korttipakkaan.  Niiden osoittamassa paikassa (indeksit 3 ja 10) on tietyt kortit (P2 ja PJ).

Lajittelualgoritmi voitaisiin lausua esimerkiksi:

 

Osoittimen ja indeksin ero on siinä, että osoittimen tapauksessa emme yleensä koskaan ole kiinnostuneita itse osoittimen arvosta (osoitteesta, siitä indeksistä missä kohdin olemme menossa), vaan osoittimen osoittaman paikan sisällöstä (sormen kohdalla olevan kortin arvo tai ei korttia).  Indeksejä käsitellessämme tutkimme monesti myös itse indeksin arvoa (tutki=3->kortit[tutki]=P2).

Osoitin voi tarvittaessa osoittaa myös itse taulukon ulkopuolelle.  Mikäli kirjoittaisimme pöydälle numeroita, voisimme osoittaa sormella yhtä hyvin pöydälle kirjoitettuja numeroita (älkää hyvät ihmiset nyt töhrätkö pöytää!) kuin pöydälle levitettyjä kortteja (taulukon alkioita).

Siis indeksit liittyvät kiinteästi taulukoihin ja osoittimet voivat liittyä mihin tahansa tietorakenteisiin alkaen yksinkertaisesta muuttujasta päätyen monimutkaisen lista-  tai puurakenteen alkioon.

Javassa tällä tavalla käyttäytyviä osoittimia vastaavat iteraattorit.  Itse asiassa Javan kaikki "oliomuuttujat" ovat osoittimia, niitä sanotaan vaan viitteiksi.  Erona esimerkiksi C++:n osoittimiin on se, että Javan viitteitä ei voi muuttaa muuta kuin osoittamaan toista alkiota.  Eli Javan viitteillä käsky "siirry yksi alkio eteenpäin" on mahdotonta.  Javan iteraattoreilla tämä sen sijaan onnistuu.  C++:ssa on aidot osoittimet - joiden kanssa voi helposti myös möhliä laittamalla osoittimen osoittamaan paikkaan johon se ei saisi osoittaa). C++:ssa on myös viitteet (reference), joita tosin ei voi siirtää mihinkään luomisen jälkeen.  C++:n iteraattorit muistuttavat jopa syntaksiltaan  C++:n osoittimia ja itse asiassa C++:n osoitin käy algoritmissa paikkaan, johon tarvitaan iteraattori.         

Kirjoita algoritmi kuvakorttien poistamiseksi taulukosta käyttäen osoittimia.

Pöytätestaa algoritmi.

 

Yksiulotteista taulukkoa voidaan verrata rivitaloon tai ruutupaperin yhteen riviin.  Kaksiulotteinen taulukko on vastaavasti kuten kapea kerrostalo tai koko ruutupaperin yksi sivu.  Tarvitsemme vastaavasti useampia osoitteita (indeksejä) osoittamaan millä rivillä ja missä sarakkeessa liikumme.

Alla on esimerkki 5x7 taulukosta (♠=pata, ♣=Risti, ♦=ruutu, ♥=hertta):

 

Jos taulukon nimi on peli, niin paikassa 3,1 on kortti pata 2:

 

Kirjoita kaikkien esimerkissä olevien korttien osoitteet em. muodossa.

 

Kaksiulotteista taulukkoa nimitetään usein matriisiksi. 

Usein taulukoiden indeksit ilmoitetaan eri järjestyksessä kuin koordinaatiston (x,y)-koordinaatit.  Tämä johtuu siitä ajattelutavasta, että taulukon rivi sinänsä voidaan kuvitella yhdeksi alkioksi (rivityypiksi) ja tällöin ilmaisu

 

tarkoittaa koko riviä (♥7, ♠2, ♦2, ♠9, ♥6, ♥3, ♦7), jonka indeksi on kolme. Mikäli tämän perään laitetaan vielä [1], niin tarkoitetaan ko. tietorakenteen alkiota jonka indeksi on yksi (♠2).

Tarvittaessa moniulotteiset taulukot voidaan muodostaa yksiulotteisenkin taulukon avulla.  Esimerkin taulukko voitaisiin muodostaa yksiulotteisesta taulukosta siten, että yksiulotteisen taulukon 7 ensimmäistä alkiota kuvaisivat matriisin 0:ta riviä, 7 seuraavaa matriisin ensimmäistä riviä jne. 

Siis mikäli yksiulotteisen taulukon nimi olisi pakka, niin voisimme käyttää samaistuksia:

 

Olemme siis numeroineet kaksiulotteisen taulukon alkiot juoksevasti.  Voimmehan tehdä näin myös kerrostalon huoneistoille tai teatterin istumapaikoille.

Taulukot voivat olla myös useampiulotteisia, esimerkiksi 3x4x5 taulukko:

 

Esitä 5 muuta sijoitusta taulukkoon.

Esitä kaava miten edellä oleva 3-ulotteinen taulukko voitaisiin esittää yksiulotteisella taulukolla.

 

Aikaisempi satunnaisen matkaajan sanastomme on oikeastaan myös kolmiulotteinen taulukko:

 

Se on kaksiulotteinen taulukko sanoista.  Mitä sitten yksi sana on?  Se on yksiulotteinen taulukko kirjaimista!

 

Siis "you" sanan indeksi on [1][2] ja sen kirjaimen "y" indeksi on [0].  Siis kaiken kaikkiaan "you"-sanan "y"-kirjaimen indeksi olisi [1][2][0].

Taulukko voitaisiin järjestää 3-ulotteiseksi myös toisinkin.  Esimerkiksi yhdessä "tasossa" olisi yksi kieli jne.

Esitä edellisessä esimerkissä kaikkien kirjainten indeksit. 

Millaisella yhden kirjaimen sijoituksella muuttaisit sanan "han" sanaksi "hon"?

Mitenkä tavallinen kirja voitaisiin kuvitella 3-ulotteiseksi taulukoksi?

Miten kirja voitaisiin kuvitella 4-ulotteiseksi taulukoksi?

Piirrä edellisiin perustuen esimerkki 4-ulotteisesta taulukosta ja anna muutama esimerkkisijoitus.

 

Osoitinmuuttuja osoittaisi myös moniulotteisessa taulukossa yhteen alkioon kerrallaan.  Esimerkiksi osoittamalla "you"-sanan "y"-kirjaimeen.

Moniulotteisen ja yksiulotteisen taulukon väliset muunnokset ovat tärkeitä, koska tietokoneen muisti (1997) on lähes aina yksiulotteinen.  Siis loogisesti moniulotteiset taulukot joudutaan lopulta aina toteuttamaan yksiulotteisina.  Onneksi useat kielet sisältävät moniulotteiset taulukot tietotyyppinä ja kääntäjät tekevät sitten muunnoksen.  Tästä huolimatta esimerkiksi C-kielessä joudutaan usein muuttamaan moniulotteisia taulukoita yksiulotteisiksi.

Taulukko voi olla myös taulukko osoittimista.  Esimerkiksi sanastomme tapauksessa kaikki sanat voisivat olla yhdessä "möykyssä":

 

Itse sanasto voisi sitten olla taulukko osoittimia sanojen alkupaikkoihin:

	0	1	2
0	00	05	09
1	11	16	19
2	23	27	31

 

Siis taulukon paikasta sanasto[1][0] löytyy osoitin.  Tämän osoittimen arvo on tässä esimerkissä 11.  Siis osoitin viittaa sanan "sinä" alkuun.  Tässä 2-ulotteinen taulukko osoittimista 1-ulotteiseen merkkitaulukkoon

 

Mitä ongelmia edellä olisi, mikäli yhdenkin sanan pituutta kasvatettaisiin?

 

Voitaisiinko edellä käyttää samoja sanoja uudestaan ja jos niin miten?

 

Osoitinmuuttujaa voitaisiin kuvitella myös seuraavasti:  Olkoon meillä osoitekirja (osoit­teet) jossa on sivuja:

sivu 0:		sivu 1:		sivu 2:
Kassinen Katto Katto 3452		Susi Sepe Takametsä -		Ankka Aku Ankkalinna 1234

 

Meidän osoitekirjamme on tavallaan taulukko osoittimista (tässä tapauksessa osoitteita, älä sotke termejä!).  Taulukon osoitteet paikassa 1 (sivu 1) on osoite "Sepe Sudelle".  Mitä tapahtuu mikäli kirjoitamme kokonaan uuden henkilön osoitteen sivulla 1 olevan osoitteen päälle (sijoitetaan uusi arvo osoitinmuuttujalle sivu[1])?

sivu 1:		C++:lla:   sivu[1] = &Batman; Javalla:   Sivu[1] = Batman;
Batman Gotham City 999

 

Mitä tapahtuu "Sepe Sudelle"?  Tuskinpa sijoitus osoitekirjassamme siirtää "Sepe Sutta" yhtään mihinkään "Perämetsästä", tai tekee edes häntä murheelliseksi!  Tämä on eräs tyypillinen virhekäsitys osoitinmuuttujia käytettäessä.  Osoitinmuuttujaan sijoittaminen ei muuta tietenkään itse tiedon sisältöä.  Mutta sijoittaminen siihen paikkaan johon osoitinmuuttuja osoittaa (esimerkissämme "Sepe Suden" asuntoon) muuttaa tietenkin myös itse tiedon sisältöä.

 

Vastaavasti jos meillä on indeksimuuttuja nimeltä snro, niin sijoitus muuttujalle

 

ei muuta mitenkään itse sivun sisältöä.  Vasta sijoitus

 

muuttaisi sivun 2 sisältöä.

Aliohjelma on tarkempi kuvaus tietylle asialle.  Tämä kuvaus esitetään jossakin toisessa kohdassa ja sitä ei suinkaan tarvitse joka kerta lukea uudelleen.

Keittokirjassa lukee:

 

Miten pullat paistetaan kauniin ruskeiksi.  Tämä olisi edellisen algoritmin aliohjelma.  Kokenut kokki ei välitä aina (eikä edes suostuisi) joka reseptin kanssa lukea itse paistamisohjetta.   Aloittelija tätä saattaisi tarvita, jottei naapuri hälyttäisi palokuntaa paikalle liian savunmuodostuksen takia.  Siis toivottavasti keittokirjasta jostakin kohti löytyisi myös itse paistamisohje.

Aliohjelmille on tyypillistä, että ne saattavat suoriutua vastaavista tehtävistä eri muuttujillekin.  Näitä kutsukerroista riippuvia muuttujia sanotaan parametreiksi. 

Esim. lihapullan paisto-ohje saattaa semmoisenaan kelvata myös tavalliselle pullalle:

 

Täydennä edellinen paistamisalgoritmi.  Onko parametreja tarpeeksi?

 

Usein helpostakin tehtävästä seuraa monia eri vaihtoehtoja, joiden täydellinen hallitseminen pelkästään päässä saattaa olla ylivoimaista.  Tällöin avuksi tulee totuus- ja päätöstaulut.  Päätöstaulu on totuustaulun pidemmälle viety versio.

Tutkikaamme aluksi muutamaa esimerkkiä jotka eivät suoranaisesti liity ohjelmointiin, mutta joissa esiintyy täsmälleen vastaava tilanne:

Uusien opiskelijoiden lähtötasotesti 1991 (n. 20% oli osannut vastata oikein tähän tehtävään):

Tehtävä 3.4:   Seisot tienhaarassa tuntemattomassa maassa. Toinen teistä vie pääkaupunkiin.  Maan asukkaat joko valehtelevat aina tai puhuvat aina totta.  Toisen tien alussa seisoskelee yksi heistä.  Esität hänelle kyllä vai ei -kysymyksen ja saat vastauksen.  Mitä kahta seuraavista neljästä kysymyksestä olisit voinut käyttää ollaksesi varma siitä, kumpi tie vie pääkaupunkiin - riippumatta siitä valehteleeko asukas vai ei?

1.  Viekö tämä tie pääkaupunkiin?

2.  Olisitko sanonut, että tämä tie vie pääkaupunkiin, jos olisin kysynyt sinulta sitä?

3.  Onko niin, että tämä joko on tie pääkaupunkiin, tai sitten sinä puhut totta (mutta ei molemmin tavoin)?

4.  Onko totta, että tämä tie vie pääkaupunkiin ja sen lisäksi sinä puhut totta?

 

Erotelkaamme eri kysymykset:

1 =	A	Viekö pääkaupunkiin?
	B	Puhutko totta? (mielenkiinnon vuoksi)
2 =	C	Olisitko sanonut että vie jos A?
3 <-	D	Tie pääk. XOR puhut totta?
4 <-	E	Tie pääk. AND puhut totta?

 

Nyt voimme kirjoittaa eri vaihtoehtojen mukaan seuraavan totuustaulun (V=vastaus kun valehteleminen otetaan huomioon):

Tie vie pää-	Puhuu	1		2		3			4
kaupunkiin	totta	A	B	C	D		V	E		V
E	E	K	K	E	E		K	E		K
E	K	E	K	E	K		K	E		E
K	E	E	K	K	K		E	E		K
K	K	K	K	K	E		E	K		K

 

Siis  2 ja 3 vastauksissa on järkevä korrelaatio siihen viekö tie pääkaupunkiin vai ei.

Mistä tiedämme milloin kaikki vaihtoehdot on kirjoitettu?  Mikäli systeemiin vaikuttavia asioita on n kappaletta ja kukin on kyllä/ei tyyppinen (0/1), niin vaihtoehdot on helpointa saada aikaan kirjoittamalla kaikki n-bittiset binääriluvut järjestyksessä (esimerkissämme n=2) ja suorittamalla sitten tarvittavat samaistukset (esim. E=0 ja K=1).  Vaihtoehtoja on tällöin 2ⁿ.

 

Olkoon meillä tehtävä, jossa yksi muuttuja voi saada arvot K,E,tyhjä ja toinen muuttuja arvot 5 ja 10.  Kirjoita kaikki ko. muuttujien kombinaatiot.

 

Mikäli meillä on vaihtoehtoja n kappaletta ja kukin voi saada k_i eri arvoa, niin montako eri kombinaatiota saamme aikaiseksi?

 

Ottakaamme toinen vastaava tehtävä:

Tehtävä 4.3:     Pekka valehtelee maanantaisin, tiistaisin ja keskiviikkoisin; muina viikonpäivinä hän puhuu totta.  Paavo valehtelee torstaisin, perjantaisin ja lauantaisin; muina viikonpäivinä hän puhuu totta.  Eräänä päivänä Pekka sanoi: "Eilen valehtelin!"  Paavo vastasi: "Niin minäkin!"  Mikä viikonpäivä oli?

 

Minä päivinä kaverukset saattaisivat sanoa ko. lausuman?  Näitä päiviä on tietysti ne, jolloin joko eilen valehdeltiin ja tänään puhutaan totta TAI eilen puhuttiin totta ja tänään valehdellaan. (XOR)

päivä	Pekka	valehteli eilen	Paavo	valehteli eilen
sunnuntai				k      sanoo
maanantai	V	sanoo
tiistai	V	k
keskiviikko	V	k
torstai		k      sanoo	V	sanoo	<==
perjantai			V	k
lauantai			V	k
sunnuntai				k      sanoo

 

Totuustaulun tavoitteena on siis kerätä kaikki mahdolliset vaihtoehdot ohjelmoijan silmien eteen, ja näin kaikki mahdollisuudet voidaan analysoida ja käsitellä.

Eräällä saarella asuu luonnonkansa.  Puolet kansan asukkaista aina valehtelevat ja toinen puoli puhuu aina totta.  Lisäksi heidän kielensä on tuntematon.  On saatu selville, että "BAL" ja "DA" tarkoittavat "kyllä" ja "ei", muttei sitä kumpiko tarkoittaa kumpaa.  He ymmärtävät suomea mutta vastaavat aina omalla kielellään.  Vastaasi tulee yksi saaren asukas.

a)  Mitä saat selville kysymyksellä "Tarkoittaako BAL KYLLÄ"?

b) Millä kysymyksellä saat selville mikä sana on kyllä?

Jälleen maahan jossa asukkaat joko valehtelevat tai puhuvat aina totta.  Tapaat kolme asukasta A:n, B:n ja C:n.  He sanovat sinulla

      A: Me kaikki kolme valehtelemme!          B: Tasan yksi meistä puhuu totta!

Mitä ovat A, B ja C?

 

Entä jos asukkaat sanovat:

      A: Me kaikki kolme valehtelemme!          B: Tasan yksi meistä valehtelee!

 

Entä jos:

      A: Minä valehtelen mutta B ei!

 

Entä jos:

      A: B valehtelee!                                             B: A ja C ovat samaa tyyppiä!

 

Vielä yksi: 

      A sanoo: B ja C ovat samaa tyyppiä.       C:ltä kysytään: Ovatko A ja B samaa tyyppiä?

Mitä C vastaa?

Ehtoja usein yhdistellään loogisten operaatioiden avulla:

 

Yksittäinen ehto antaa tulokseksi tosi (T=true) tai epätosi (F=false).  Ehtojen tulosta voidaan usein myös kuvata 1 tai 0.  Ehtojen yhdistämistä loogisilla operaatioilla kuvaa seuraava totuustaulu (myös C++:n loogiset operaattorit merkitty):

ja

tai

ehd. tai

ei

AND

OR

XOR

NOT

p

q

p

&&

q

p

||

q

p

^

q

!

p

^ toimii jos p ja q boolean

F

0

F

0

F

0

F

0

F

0

T

1

F

0

T

1

F

0

T

1

T

1

T

1

T

1

F

0

F

0

T

1

T

1

F

0

T

1

T

1

T

1

T

1

F

0

F

0

 

Huomattakoon edellä, että AND operaatio toimii kuten kertolasku ja OR operaatio kuten yhteenlasku (mikäli määritellään 1+1=1).  Siis loogisia operaattoreita voidaan käyttää kuten normaaleja algebrallisia operaattoreita ja niillä operoiminen vastaa tavallista algebraa.  Loogisten operaatioiden algebraa nimitetään Boolen -algebraksi.

Ehtojen sieventämisessä käytettäviä kaavoja voidaan todistaa oikeaksi totuustaulujen avulla.  Todistetaan esimerkiksi de Morganin kaava (vrt. joukko-oppi, 1=true, 0=false):

 

		e1	e2	e3
p	q	p AND q	NOT p	NOT q	NOT e1	e2 OR e3
0	0	0	1	1	1	1
0	1	0	1	0	1	1
1	0	0	0	1	1	1
1	1	1	0	0	0	0

 

Koska kaksi viimeistä saraketta ovat samat ja kaikki muuttujien p ja q arvot on käsitelty, on laki todistettu!

Todista oikeaksi myös toinen de Morganin kaava:

 

NOT (p OR q) = (NOT p) AND (NOT q)

Yhteenlaskun ja kertolaskun välillähän pätee osittelulaki:

      p * (q + r) = (p * q) + (p * r)

Samaistamalla * <=> AND ja + <=> OR todetaan loogisille operaatioillekin osittelulaki:

  p AND (q OR r) = (p AND q) OR (p AND r)

Todista oikeaksi toinen osittelulaki (toimiiko vast. yhteenlaskulla ja kertolaskulla):

  p OR (q AND r) = (p OR q) AND (p OR r)

 

			e1	e2	e3
p	Q	r	q AND r	p OR q	p OR r	p OR e1	e2 AND e3
0	0	0
0	0	1
0	1	0
0	1	1
1	0	0
1	0	1
1	1	0
1	1	1

 

Huomaa, että totuustauluun tulee nyt 8 riviä (koska kolme muuttujaa)!

Käytä de Morganin kaavoja tai osittelulakia seuraavien ehtojen sieventämiseen:

a)  ei ole totta että hinta alle 5 mk ja paino yli 10 kg

b)  NOT (kello<=7 OR rahaa>50 mk)

c)   ((hinta < 5) tai (rahaa>10)) ja ((hinta < 5) tai (kello>9))

Mikäli edellä esitetyt asiat tuntuvat ymmärrettäviltä, niin ohjelmoinnissa ei tule olemaan mitään vaikeuksia.  Jos vastaavat asiat tuntuvat vaikeilta ohjelmoinnin kohdalla, kannattaa palata takaisin tähän lukuun ja yrittää samaistaa asioita ohjelmointikieleen.    

Taulukoiden samaistaminen ruutupaperiin, korttipakkaan tai muuhun tuttuun asiaan auttaa asian käsittelyä.  Osoitinmuuttuja on yksinkertaisesti jokin (vaikkapa sormi) joka osoittaa johonkin (vaikkapa yhteen kirjaimeen).

Silmukat ja ehtolauseet ovat hyvin luonnollisia asioita. 

Aliohjelmat ovat vain tietyn asian tarkempi kuvaus.  Tarvittaessa tiettyä asiaa ei ongelmaa tarvitse heti ratkaista, vaan voidaan määritellä aliohjelma, joka hoitaa homman ja kirjoitetaan itse aliohjelman määrittely joskus myöhemmin.

C-kielessä merkkijonot tullaan esittämään taulukoina kirjaimista.  Merkkijonon loppu ilmaistaan kirjaimella NUL.  Siis esimerkiksi Kissa olisi seuraavan näköinen

 

0	1	2	3	4	5
K	i	s	s	a	NUL

 

Kirjoita seuraavat algoritmit.  Erityisesti kirjoita ensin algoritmin sanallinen versio

1.   Välilyöntien poistaminen jonon alusta.

2.   Välilyöntien poistaminen jonon lopusta.

3.   Ylimääräisten (2 tai useampia) välilyöntien poistaminen jonosta.

4.   Kaikkien ylimääräisten (alku-, loppu- ja monikertaiset) välilyöntien poistaminen.

5.   Jonon muuttaminen siten, että kunkin sanan 1. kirjain on iso kirjain.

6.   Tietyn merkin esiintymien laskeminen jonosta.

7.   Esiintyykö merkkijono toisessa merkkijonossa (kissatarha, sata-> esiintyy; kissatarha, satu-> ei esiinny).

Kirjoita seuraavat algoritmit:

1.   Onko vuosi karkausvuosi vai ei. (Huom! 1900 ei, 2000 on)

2.   Montako karkausvuotta on kahden vuosiluvun välillä.

3.   Jos 1.1 vuonna 1 oli maanantai, niin mikä viikonpäivä on 1.1 vuonna x?  (Oletetaan että kalenteri olisi ollut aina samanlainen kuin nytkin.  Vihje!  Tutki almanakkaa peräkkäisiltä vuosilta.)

4.   Onko päivämäärä pp.kk.vvvv oikeata muotoa?

 

Ompi Jaavaa ompi Ceetä,

Adaa ompi Pascalia.

Kieltä vanhaa, kieltä uutta

ne kaukaa sekä läheltä.

 

Monta kieltä monta mieltä,

kummajaisilla ku noilla,

voi koodia väänneskellä,

kaikellailla keikistellä.

 

Mitä tässä luvussa käsitellään?

•  katsotaan mitä syntaktista eroa on eri ohjelmointikielillä yksinkertaisessa esimerkissä

 

Jossakin vaiheessa ohjelmoinnin opiskelua tullaan siihen, että ohjelma pitäisi toteuttaa jollakin olemassa olevalla ohjelmointikielellä (on tosin ohjelmointikursseja, joilla käytetään keksittyä ohjelmointikieltä).

Seuraavassa esitämme ohjelman jonka ainoa tehtävä on tulostaa teksti:

   Terve!  Olen ??-kielellä kirjoitettu ohjelma.

Itse ohjelman suunnittelu on tällä kertaa varsin triviaali ja tehtävä ei tarvitse varsinaista tarkennustakaan, kaikki on sanottu tehtävän määrityksessä.  Siis valitaan vain käytetyn kielen tulostuslause.

Jotta lukija ymmärtäisi, ettei eri kielten välillä ole kuin pieni ero, esitämme ohjelman useilla eri kielillä.  Ohjelman lopun jälkeen olevan poikkiviivan alapuolella on mahdollisesti esitetty miten ohjelmaa voitaisiin kokeilla MS-DOS-koneessa:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Siis erot eri kielten välillä ovat hyvin kosmeettisia (Pascalin BEGIN on C:ssä { jne.).  Jollakin kielellä asia pystyttiin esittämään hyvin lyhyesti ja jossakin tarvitaan enemmän määrittelyjä.  Ainoastaan assembler-versio on sellaisenaan epäselvä, suoritettavia lauseita on täytynyt kommentoida enemmän.

Kullakin ohjelmointikielellä on omat etunsa.  Pascal on hyvin tyypitetty kieli ja sillä ei ole aloittelijankaan niin helppo tehdä eräitä tyypillisiä ohjelmointivirheitä kuin muilla kielillä.  Standardi Pascal on kuitenkin hyvin suppea ja siitä puuttuu esim. merkkijonojen käsittely. 

Turbo Pascalin laajennukset tekevät kielestä erinomaisen ja nopean kääntäjän ja UNIT-kirjastojen ansiosta se on todella miellyttävä käyttää.  Nykyisin lisäksi Delphi-sovelluskehittimen kielenä on juuri Turbo Pascalista laajennettu Object Pascal.  Delphi on eräs merkittävimmistä ja helppokäyttöisimmistä työkaluista Windows-ohjelmointiin.

BASIC-kieli on yleensä suppea kieli ja siksi helppo oppia.  Lukuisten eri murteiden takia ohjelmien siirtäminen ympäristöstä toiseen on lähes mahdotonta.  Microsoftin Visual Basic on kuitenkin Windows-ympäristössä nostanut Basicin jopa ohjelmankehittäjien työkaluksi.  Alkuperäiset Basic-murteet olivat huonoja opiskelukieliä rajoittuneiden rakenteiden ja automaattisen muuttujanluomisen vuoksi.  Visual Basicin uusimmissa versioissa on jo mukana yleisimmin tarvittavat rakenteet.

Fortran on luonnontieteellisissä sovelluksissa eniten käytetty kieli ja siihen on saatavissa laajat aliohjelmakirjastot useisiin numeriikan ongelmiin.  Mikroissa kääntäjät ovat kuitenkin hitaita.  Fortran-77 standardi on eräs parhaista standardeista, jota seuraamalla ohjelma toimii lähes koneessa kuin koneessa.  Fortranin uusin standardi -90 tarjoaa ennen kielestä puuttuneet rakenteet.

ADA on Pascalin kaltainen vielä tarkemmin tyypitetty kieli, jossa on joitakin olio-ominaisuuksia.  Se on Yhdysvaltain puolustusministeriön tukema kieli, joten se lienee tulevaisuuden kieliä.  Sopii erityisesti raskaiden reaaliaikatoteutusten kirjoittamiseen (esim. ohjusjärjestelmät).  GNU ADA tuo kääntäjän käyttämisen mahdolliseksi jokaiselle.  Lisäksi ADA-95 tuo kieleen olio-ominaisuudet.

C-kieli on välimuoto Pascalista ja konekielestä.  Ohjelmoijalle sallitaan hyvin suuria vapauksia, mutta toisaalta käytössä on hyvät tietotyypit ja rakenteet.  Hyvä kieli osaavan ohjelmoijan käsissä, mutta aloittelija saattaa saada aikaan katastrofin. ANSI-C on suhteellisen hyvin standardoitu ja sitä seuraamalla on mahdollista saada ohjelma toimimaan pienin muutoksin myös toisessakin laiteympäristössä.  Lisäksi ANSI-C:n tuoma funktioiden prototyypitys ja muutkin tyyppitarkistukset poistavat suuren osan ohjelmointivirheiden mahdollisuuksista, eivät kuitenkaan kaikkia. UNIX -käyttöjärjestelmän leviämisen myötä C on kohonnut erääksi kaikkein käytetyimmistä kielistä.

C++ on C-kielen päälle kehitetty oliopohjainen ohjelmointikieli.  Aikaisemmin C-kielellä oli niin suuri merkitys, että se kannatti ehkä opetella aluksi.  Nykyisin jokainen merkittävä C-kääntäjä on myös C++-kääntäjä.  Oliopohjaisen ohjelmoinnin kannalta on parempi mitä aikaisemmin olio-ohjelmointi opetellaan.  Valitettavasti C++ ei ole hybridikielenä (multi paradigm) paras mahdollinen ohjelmoinnin opetteluun.  Kuitenkin paremmin opetteluun soveltuvat kielet ovat usein "leikkikieliä", kuten alkuperäinen Pascalkin oli.  Delphi olisi mahtavan graafisen kirjastonsa ja kehitysympäristönsä ansiosta loistava opettelutyökalu, valitettavasti vaan lehti-ilmoituksissa harvoin haetaan Delphi-osaajia!  Kohtuullisena kompromissina  C++:kin  voidaan valita opettelukieleksi, kunhan ei heti yritetä opetella kaikkia kielen kommervenkkeja. 

Java on verkkoympäristössä tapahtuvaan ohjelmointiin kehitetty oliokieli.  Javan erikoisuus on se, että se käännetään siirrettävään Java-tavukoodimuotoon.  Tätä tavukoodia voidaan sitten suorittaa lähes missä tahansa ympäristössä Java-virtuaalikoneen avulla. Javaa on sanottu C++:aa yksinkertaisemmaksi, mutta kuitenkin Java kirjat ovat yhtä paksuja kuin C++ kirjatkin.  Nykyisin onkin monesti niin, ettei itse kieli ole ongelma, vaan sille kehitettyjen aliohjelmakirjastojen opettelu ja käyttö.  Javan suurimpana etuna on sen lähes kaikissa koneissa toimiva graafinen kirjasto.  Java-työkalut kehittyvät kovaa vauhtia, valitettavasti käyttöliittymän graafiseen suunniteluun tarkoitetut työkalut eivät ole keskenään yhteensopivia.

C# on Microsoftin vuonna 2000 julkaisema oliopohjainen ohjelmointikieli. Syntaksiltaan se on muistuttaa paljon C:tä, mutta sen kehityksessä on otettu paljon inspiraatiota myös Javasta, Delphistä ja Visual Basicista. Javan ja C#:n samankaltaisuus on ollut jonkinlainen kiistelyn aihe jopa kielten kehittäjien kesken. Kielten viimeisimmät päivitykset ovat kuitenkin tuoneet kehittyneimpiin ominaisuuksiin huomattavia eroja. Hyvänä esimerkkinä C#:n 3.0:ssa esitelty Language Integrated Query (LINQ) laajennus toi kieleen monia funktionaalisen ohjelmoinnin ominaisuuksia. Javan tavoin myös C# ohjelmat ajetaan virtuaalikoneen päällä. Käytettävä virtuaalikone perustuu Microsoftin Common Language Infastructure spesifikaatioon. Suosituin CLI toteutus on Microsoftin oma virtuaalikone, mutta myös muutama vapaan lähdekoodin vaihtoehto kuten Mono on saatavilla.

Tämän kurssin eri versioissa on käytetty esimerkkikielenä Pascalia, C:tä, C++:aa ja nyt tässä versiossa Javaa. Kielen valinta ei suuria merkitse, ohjelmointi on kuitenkin perusteiltaan samanlaista.  Joitakin vivahde-eroja kuitenkin tulee valitun kielen mukana.

 

Kommenttit jo käyttämäksi

muistiksipa merkit muille

selvennykseksi sepille

omaksikin ovat iloksi.

 

Vakioksi alkuun tiedot

kevenee koodin korjaaminen

mukavampi muutos aina

sulavampi säätäminen.

 

Koodi ensin käännettävä

syntaksikin syynättävä

tuo tulkilla tulkattava

siitä sitten suorittava.

 

 

Mitä tässä luvussa käsitellään?

•  Java-kielisen ohjelman peruskäsitteet

•  kääntämisen ja linkittämisen merkitys

•  paketin käyttöönotto

•  vakioarvot

 

 

Luvun esimerkkikoodit:

 

Ohjelman toteuttamista varten täytyy valita jokin todellinen ohjelmointikieli.  Lopullisesta ohjelmasta ei valintaa toivottavasti huomaa.  Valitsemme käyttökielen tällä kurssilla puhtaasti "markkinaperustein": paljon käytetyn ja työelämässä kysytyn - Java.

Mikäli olet käynyt jo Ohjelmointi 1 kurssin C#:lla, niin ei turhaan kannata säikähtää kielen vaihtumista. Java ja C# ovat ominaisuuksiltaan hyvin samankaltaisia kieliä. Molemmat ovat staattisesti tyypitettyjä olio-ohjelmointikieliä, molempien suoritus tapahtuu virtuaalikoneessa ja lisäksi ne ovat hyvin samankaltaisia jopa syntaksiltaan.

Erot käsitellään tässä monisteessa sitä mukaan kun niitä tulee vastaan. Merkittävimmät niistä koskevat kuitenkin vasta kielten uudempia ja kehittyneempiä ominaisuuksia, eikä niitä ole edes Ohjelmointi 1 kurssin puitteissa tullut vastaan. Internetissä on monia eroista kielten eroa käsitteleviä artikkeleita, mutta yksi hyvä paikka on Ville Salosen kandinaatintutkielma:

Ville on myös pohtinut esseessään hieman edistyneempää asiaa ja syitä eroavaisuuksiin. Näkökulma on enemmänkin "konepellin alta", joten seuraava linkki voi olla hyvää luettavaa tämän kurssin jälkeen.

 

Tarpeen vaatiessa monisteen muutamaan ensimmäiseen lukuun Java-kielisten esimerkkien rinnalle on kirjoitettu myös C# versiot. Kurssin kannalta C#:n osaaminen ei kuitenkaan ole olennaista.

 

 

Ohjelmat ovat selvästikin hyvin samankaltaiset. Ensimmäiseksi kannattaa kiinnittää huomio syntaksiin. Javan (yleisesti käytetty) tapa aloittaa lohko { -merkillä ilman rivinvaihtoa eroaa hieman C#:n vastaavasta. Molemmat ohjelmat kääntyisivät kummallakin tavalla, mutta koodin luettavuus helpottuu, kun käyttää virallista tyyliä. Lisäksi kehitysympäristöjen tarjoamien koodin formatointityökalujen käyttö on helpompaa jos oletusasetuksia ei tarvitse erikseen muuttaa. Vähän tärkeämpi koodin muotoiluun liittyvä asia on, että funktiot on tapana kirjoittaa Javassa pienellä, kun C#:n käytäntö on nimetä ne isolla. Jälleen kuitenkin kumpikin tyyli menee molempien kääntäjistä läpi.

On myös helppo huomata että käytettyjen kirjastojen ja funktioiden nimet ovat muutenkin erilaiset. Silti usein tulee vastaan tilanteita, joissa käytettyjen kirjastojen nimet ovat, jolleivät peräti samoja, niin ainakin hyvin samankaltaisia. Tähän liittyy kuitenkin se ansa, että samallakin tavalla nimettyjen funktioiden toiminta saattaa erota ratkaisevasti toisistaan! Esimerkiksi C#:issa usein viedään parametrina alku ja osavälin pituus kun Javassa viedään parametrina alku ja loppu-indeksi, joka ei enää tule mukaan.  Jos aloitetaan esimerkiksi jonon alusta, niin silloin samat parametrin arvot toimivat molemmilla, mutta muussa tapauksessa ei:

 

Javassa jälkimmäinen lause tuottaa bc, mutta C#:ssa bcd. Syy selviää metodien dokumentaatiota tutkimalla. Ensimmäinen esimerkki tulostaa merkkijonon joka alkaa paikasta (kirjaimesta) kaksi ja loppuu kolmanteen paikkaan, kun taas toinen ottaa toisesta paikasta lähtien kolme merkkiä.

 

Kannattaa siis aluksi varmistaa dokumentaatiosta mitä onkaan tekemässä. Ohjelmointikielien samankaltaisuuksista huolimatta jokaisella kielellä on omat tapansa toteuttaa asioita. Se minkä vuoksi Javan substring metodin viimeinen parametri 3 ei sisällytäkään vastaavaa merkkiään palautettavaan merkkijonoon, johtuu Javan käytännöstä jättää merkki pois (exclude), joka on tyypillistä toiminnallisuutta useille Java-funktioille. Valittu tapa säästää käytännössä usein turhia -1 laskuja.

Kirjoita Java-ohjelma joka tulostaa:

 

Ohjelmakoodi kirjoitetaan millä tahansa tekstieditorilla tekstitiedostoon vaikkapa nimelle Hello.java.  Yleensä tiedoston tarkentimella annetaan sille tyyppi, jonka avulla käyttöjärjestelmä ja ohjelmat saavat lisätietoa minkälainen tiedosto on kyseessä.

Valmis tekstitiedosto käännetään ko. kielen kääntäjällä.  Käännöksestä muodostuu usein objektitiedosto, joka on jo lähellä lopullisen ohjelman konekielistä versiota.  Objektitiedostosta puuttuu kuitenkin mm. kirjastorutiinit.  Kirjastorutiinien kutsujen kohdalla on "tyhjät" kutsut. 

Java-kielen tapauksessa käännöksen tuloksena syntyy Java-virtuaalikoneen (JVM) ymmärtämää tavukoodia.  Esimerkin tiedosto kääntyy esimerkiksi komennolla:

 

Käännöksen tuloksena syntyvässä Hello.class-tiedossa on siis Java-tulkin ymmärtämää tavukoodia.  Kuitenkin siitäkin puuttuu itse kirjastorutiinit.  Erona muihin kieliin on se, että käännetty tiedosto toimii niissä ympäristöissä, joissa on JVM ja nuo puuttuvat rutiinit.

Varsinaisissa käännettävissä kielissä käännös pitää suorittaa uudelleen jos ohjelma halutaan siirtää toiseen ympäristöön.

Linkittäjällä (kielestä riippumaton ohjelma) liitetään kirjastorutiinit käännettyyn objektitiedostoon. Linkittäjä korvaa tyhjät kutsut varsinaisilla kirjastorutiinien osoitteilla, kunhan se saa selville mihin kohti muistia kirjastorutiinit sijoittuvat. Näin saadaan valmis ajokelpoinen konekielinen versio alkuperäisestä ohjelmasta.

Javan tapauksessa varsinaista linkittämistä ei tarvita, vaan ohjelman suorituksen aikana etsitään tarpeellisia luokkia.  Luokkien etsiminen voi tapahtua heti kun ensimmäistä luokkaa ladataan muistiin ("static" resolution) tai vasta kun luokkaan viitataan ("laziest" resolution).

Käännetty ohjelma ajetaan käyttöjärjestelmästä riippuen yleensä kirjoittamalla ohjelman alkuperäinen nimi.  Tällöin käyttöjärjestelmän lataaja-ohjelma lataa ohjelman konekielisen version muistiin ja siirtää prosessorin ohjelmalaskurin ohjelman ensimmäisenä suoritettavaksi tarkoitettuun käskyyn.  Vielä tässäkin vaiheessa osa aliohjelmakutsujen osoitteista voidaan muuttaa vastaamaan sitä todellista osoitetta, johon aliohjelma muistiin ladattaessa sijoittui.  Tämän jälkeen vastuu koneen käyttäytymisestä on ohjelmalla.  Onnistunut ohjelma päättyy aina ennemmin tai myöhemmin käyttöjärjestelmän kutsuun, jossa ohjelma pyydetään poistamaan muistista.

Kuva 6.1  Ohjelman kääntäminen ja linkittäminen

Javan tapauksessa ajaminen suoritetaan antamalla .class tai .jar tiedosto Java-virtuaalikoneelle (Java Virtual Machine, JVM). Esimerkkimme tapauksessa komennolla

 

Jos luokasta Hello löytyy julkinen luokkametodi (staattinen metodi) nimeltä main, niin ohjelman suoritus aloitetaan siitä.  Mikäli metodia ei löydy, tulee virheilmoitus:

 

 

Kuva 6.2  Java-ohjelman kääntäminen ja linkittäminen

 

Alkuperäisellä editorilla kirjoitetulla ohjelmakoodilla ei ole tavallista kirjettä kummempaa virkaa ennen kuin teksti annetaan kääntäjäohjelman tutkittavaksi.  Käännöksen jälkeen alkuperäinen teksti voitaisiin periaatteessa vaikka hävittää - käytännössä se tietysti säilytetään mm. ylläpidon takia.  Siis me kirjoitamme tekstiä, joka ehkä (toivottavasti) muistuttaa Java-kielen syntaksin mukaista ohjelmaa.  Vasta käännös ja linkkaus tekevät todella toimivan ohjelman.

On olemassa ohjelmankehitysympäristöjä, joissa editori, kääntäjä ja linkkeri (sekä mahdollisesti debuggeri, virheenjäljitin) on yhdistetty käyttäjän kannalta yhdeksi toimivaksi kokonaisuudeksi.  Esimerkkeinä Eclipse, NetBeans, Microsoftin Visual Studio ja Borland-C++ Builder . Kaikissa listassa mainituissa kehittimissä on myös tuki käyttöliittymän suunnittelulle.

Esimerkiksi Borlandin ympäristöissä ohjelma kirjoitetaan tekstinä ja kun ohjelmakoodi on valmis, saadaan koodi käännettyä, linkitettyä ja ladattua ajoa varten vain painamalla [F9](tai [Ctrl-F9] versiosta riippuen).

Mahdollisia muita integroitujen ympäristöjen ominaisuuksia ovat mm: UML-kaavioiden ja muiden dokumenttien automaattinen tuottaminen (esim. Delphin ModelMaker, JavaDoc-yhteistoiminta Java-kehittimissä), jotka perinteisesti ovat olleet CASE-suunnitteluohjelmien aluetta. Lisäksi myös koodin generointi kaavioista onnistuu rajoitetusti.

Seuraavaksi tutkimme ohjelmaa lause kerrallaan:

 

tai

 

Ohjelman  alussa on kommentoitu mitä ohjelman tekee.  Yleensä ohjelmakoodit on hyvä varustaa kuvauksella siitä, mitä ohjelma tekee, kuka ohjelman on tehnyt, milloin ja miksi.  Milloin ohjelmaa on viimeksi muutettu, kuka ja miten.

Lisäksi jokainen vähänkin ei-triviaali lause tai lauseryhmä kommentoidaan.  Kommenttien tarkoituksena on kuvata ohjelmakoodia lukevalle lukijalle se mistä on kyse.

Lohkokommentti alkaa /* -merkkiyhdistelmällä ja päättyy */ -merkkiyhdistelmään.  Lohkokommentteja voidaan sijoittaa Java-koodissa mihin tahansa mihin voitaisiin pistää myös välilyönti.  Rivin loppuminen ei sinänsä lopeta lohkokommenttia.  Kommentin sisällä SAA esiintyä / ja *-merkkejä yhdessä tai erikseen, muttei lopettavaa yhdistelmää */.

Yleinen virhe on unohtaa lohkokommentin loppusulku pois.  Mikäli esimerkissämme puuttuisi kommentin loppusulku, olisi koko loppuohjelma kommenttia ja mitään ohjelmaa ei siis olisikaan.  Mikäli kääntäjä antaa vyöryn ihmeellisiä virheilmoituksia, kannattaa aina ensin tarkistaa kommenttisulkujen täsmäävyys.  Tosin tähän auttaa nykyisten ohjelmointiympäristöjen värikoodien käyttö eri ohjelman osille, eli esimerkiksi kommentit näkyvät eri värisinä ja puuttuva komenttisulku paljastuu välittömästi.

Javassa yhden rivin kommentti voidaan ilmaista myös // -merkkiyhdistelmällä, jolloin rivinloppu lopettaa kommentin. 

Itse ohjelmakoodi kommentoidaan seuraavasti:

•  selviä kielen rakenteita ei saa kommentoida.  Ei siis

•  kuitenkin mikäli lauseella on selvä merkitys algoritmin kannalta, kommentoidaan tämä

•  ryhmitellään lauseet tyhjien rivien avulla loogisiksi kokonaisuuksiksi.  Tällaisen kokonaisuuden alkuun voidaan laittaa kommenttirivi, joka kuvaa kaikkien seuraavien lauseiden merkitystä.

•  mikäli tekee mieli kommentoida lauseryhmä, kannattaa miettiä voitaisiinko koko ryhmä kirjoittaa aliohjelmaksi.  Aliohjelman nimi sitten kuvaisi toimintaa niin hyvin, ettei kommenttia enää tarvittaisikaan.  Kuitenkin jos näin suunnitellulle aliohjelmalle tulee iso kasa (liki 10) parametreja, täytyy asiaa ajatella uudestaan.

•  muuttujien nimet valitaan kuvaaviksi.  Kuitenkin mitä lokaalimpi muuttujan käyttö, sitä lyhyemmäksi nimi voidaan jättää. i ja j sopivat aivan hyvin silmukkamuuttujien nimiksi ja p yms. osoittimen nimeksi (lokaalisti).

•  globaaleja muuttujia vältetään 'kaikin keinoin'

•  olioiden ansiosta globaalit muuttujat voidaan yleensä välttää kokonaan!

•  vakiotyyliset (alustetaan esittelyn yhteydessä eikä ole tarkoitus ikinä muuttaa) globaalit muuttujat on sallittu sellaisenaan ja niiden nimet kannattaa ehkä kirjoittaa isolla.

•  funktioiden paluuarvolle valitaan tietty tyyli, joka pyritään säilyttämään koko ohjelman ajan.  Esimerkiksi true = onnistui ja false epäonnistui.

 

Jos tiedot annetaan Javan dokumentoinnin standardimuodossa, niin tiedostoista saadaan sitten koostettua helposti HTML-muotoinen dokumentti. JavaDocin mukainen kommentti alkaa "sululla" /** ja päättyy normaaliin kommentin loppumerkkiin.

Dokumentaatiokommenttien käyttö helpottaa dokumentaation hallitsemista. Muuttaessaan funktion toiminnallisuutta ohjelmoijan on helppo muuttaa myös dokumentaatiota, koska se on saatavilla samasta paikasta. Lisäksi kehittyneet ohjelmointiympäristöt osaavat lukea ja näyttää oikein muodostetun dokumentaation automaattisesti koodia kirjoittaessa.

Kommentointi kannattaa käytännössä tehdä yksittäisten metodien tarkkuudella.  Myös tämän monisteen esimerkeistä on pyritty tekemään JavaDocin mukaisia

Lisäinformaatiota dokumentaatioon annetaan tagien muodossa @-merkillä ja sen jälkeen tulevalla avainsanalla. Esimerkistä löytyvät koodin tekijän ja version ilmoittavat @author ja @version -tagien käyttäminen on hyödyllistä vaikkapa tiimeissä tapahtuvissa ohjelmointiprojekteissa. Kaksi muuta tärkeää merkintää ovat aliohjelmatasolla käytettävät @param ja @return, joilla kuvaillaan halutut parametrit ja palautettava arvo.

Katso lisää ohjeita JavaDocin ja tagien käytöstä osoitteessa

 

Mikäli käytetty editori ei tue automaattisesti kommentointia, kannattaa kirjoittaa aina tarvittavat kommentit vaikka tiedostoihin a.t (alku) jam.t (metodi) ja opetella käyttämään editorin "lisää tiedosto" toimintoa.

Harvoin voi tehdä ohjelman joka tulee täysin toimeen ilman muiden apua. Javan tapauksessa ilman muiden luokkien apua.  Jotta kääntäjä tietäisi mistä puhutaan, pitää kertoa mistä paketista luokka löytyy.  Paketista java.lang löytyy System-niminen luokka, josta löytyy tarvitsemamme out-olio.  Eli pitäisi oikeastaan kirjoittaa:  

 

Olioihin ja luokkiin paneudumme tarkemmin luvussa 9.

Jos kuitenkin samaan luokkaa tarvitaan useasti ja halutaan lyhentää kirjoittamista, voidaan import-lauseella kertoa ennen varsinaista koodin aloittamista apuna tarvittavat luokat. 

 

Jos haluttaisiin ottaa kaikki tietyn paketin luokat käyttöön, tämä voitaisiin tehdä rivillä:

 

Poikkeuksen muodostaa paketti java.lang jota ei tarvitse välttämättä erikseen esitellä lainkaan.  Näinhän oli tehty ensimmäisessä esimerkissämme.

C# osaajille tiedoksi, että using sanalla on vastaava toiminnallisuus on C#:ssa kuin importilla. C# ei kuitenkaan tue jokerimerkin käyttöä, joten kaikki kirjastot määritellään siinä täsmällisesti.

 

Jokainen Java-ohjelma sisältää vähintään yhden julkisen luokan.  Kunkin tiedoston nimi on oltava sama kuin tiedostossa olevan julkisen luokan nimi + '.java'. Palaamme luokkiin ja olioihin tarkemmin hieman myöhemmin.  Usein olio-ohjelmoinnissa on tapana että luokkien nimet aloitetaan isolla kirjaimella.

Luokan esittely ja toteutus alkaa aaltosululla { ja päättyy toiseen lopettavaan aaltosulkuun }.

 

Kun Java-tavukoodi ladataan muistiin, etsitään ensin ladatusta luokasta (tai muuten erikseen ilmoitetusta luokasta) pääohjelmaa, josta koodin suoritus aloitetaan.  Pääohjelman nimi on aina oltava main.  Oikeassa ohjelmassa on pääohjelman lisäksi useita luokkia ja metodeita (luokkien sisällä olevia aliohjelmia). 

main-­metodi voi olla myös useammassa luokassa, jolloin kullakin main-metodilla voidaan testata kyseisen luokan toiminta.  Näin helpotetaan yksikkötestausta (modulitestausta).  Tästä lisää kun pääsemme tarkemmin olioiden ja luokkien kimppuun. Huom! Javassa vain luokkien nimet aloitetaan isolla kirjaimella.

Seuraavaksi esitellään ohjelman pääohjelma ("oikea" ohjelma koostuu isosta kasasta aliohjelmia ja yhdestä pääohjelmasta, jonka nimi on main). 

public      tarkoittaa, että metodi on julkisesti näkyvä.  Muuten metodi ei näkyisi luokan ulkopuolelle eikä sitä voitaisi suorittaa.

static      tarkoittaa että metodi on ns. luokkametodi, eli se voidaan suorittaa, vaikkei luokasta olisi olemassa yhtään esiintymää eli oliota.  Luokkametodi ei voi käyttää luokan olioiden attribuutteja suoraan (koska oliota ei välttämättä ole).

void        ilmoittaa, että metodi jota kirjoitamme ei palauta mitään arvoa (eng. void = mitätön).

main        tarkoittaa pääohjelman nimeä.  Tämä TÄYTYY aina olla main.  Muut metodit voidaan nimetä vapaasti.

(           Metodin parametrilistan (argumenttilistan) alkusulku.

String[]           ilmoittaa että metodi saa parametrinaan taulukollisen (hakasulut tarkoittavat taulukkoa) merkkijonoja.  Nämä ovat merkkijonot tulevat ohjelmaan käynnistyksen yhteydessä olevina parametreina. Käynnistys parametreja voi olla nolla tai useita.

args        itse keksitty nimi jolla merkkijonotaulukkoon viitataan.  Tämä nimi voi olla mikä tahansa.

)           Metodin parametrilistan (argumenttilistan) loppusulku.

Ohjelma

 

 

Tulostaisi seuraavalla tavalla:

 

{ }                         Javassa isompi joukko lauseita kootaan yhdeksi lauseeksi sulkemalla lauseet aaltosulkuihin.  Metodin täytyy aina sisältää aaltosulkupari, vaikka siinä olisi vain 0 tai 1 suoritettavaa lausetta.

 

System      on paketista java.lang löytyvä luokka, jossa on joukko hyödyllisiä oliota ja metodeja.

out         on Systemluokan olio, joka sisältää mm. tulostukseen tarvittavia metodeja.

println("?") tulostaa ajonaikana sen tekstin, joka on lainausmerkkien välissä.  Tulostuksen jälkeen vaihdetaan uudelle riville. Jos tarvitsee tulostaa useita eri tekstejä tai muuttujia välissä, voidaan niistä muodostaa +-operaatiolla uusi merkkijono, esimerkiksi:

 

;                            puolipiste lopettaa lauseen.  Puolipiste voidaan sijoittaa mihin tahansa lopetettavaan lauseeseen nähden.  Sen eteen voidaan jättää välilyöntejä tai jopa tyhjiä rivejä.  Sen pitää kuitenkin esiintyä ennen uuden lauseen alkua.   Näin Java-kieli ei ole rivisidonnainen, vaan Java-kielinen lause voi jakaantua usealle eri riville tai samalla rivillä voi olla useita Java-kielisiä lauseita.

Puolipisteen unohtaminen on tyypillinen syntaksivirhe.  Ylimääräiset puolipisteet aiheuttavat tyhjiä lauseita, joista tosin ei ole mitään haittaa: "Tyhjän tekemiseen ei kauan mene" - sanoo tyhjän toimittaja.

Isoilla ja pienillä kirjaimilla on Java-kielessä eri merkitys.  Siis EI VOIDA KIRJOITTAA:

 

Välilyöntejä, tabulointimerkkejä, rivinvaihtoja ja sivunvaihtoja nimitetään yleisesti yhteisellä nimellä "white space".  Käännettäessä kommentit muutetaan yhdeksi välilyönniksi, joten myös kommenteista voitaisiin käyttää nimitystä "white space".  Jatkossa käytämme nimitystä tyhjä tai tyhjä merkki, kun tarkoitamme "white space".

Java-koodi voi sisältää tyhjiä merkkejä missä tahansa, kunhan niitä ei kirjoiteta keskelle sanaa tai tekstiä määrittelevän ""-parin ollessa auki. ""-parin sisällä tyhjätkin merkit ovat merkityksellisiä.

Siis kääntäjän kannalta malliohjelmamme voitaisiin kirjoittaa myös seuraavillakin tavoilla:

 

 

 

Yleinen tyyli on kuitenkin jakaa koodia riveihin ja sisentää lohkoja muutamalla pykälällä.  Kunnes lukija on varma omasta tyylistään, kannattaa matkia tässä monisteessa (ei kuitenkaan edellisiä esimerkkejä) esitettyä kirjoitustapaa ohjelmille.

Voimme määritellä ohjelmaamme vakioita; eli arvoja jotka esiintyvät ohjelmassa täsmälleen yhden kerran.  Näin ohjelmastamme saadaan helpommin muuteltava.  Esimerkiksi seuraava ohjelma tulostaisi myös tekstin "Hello world!": .  Vakioiden nimet on tapana kirjoittaa isoilla kirjaimilla.

 

Kirjoita edellisestä ohjelmasta suomenkielellä tulostava versio (= suomenna ohjelma).

Kirjoita aikaisemmasta "Matti Meikäläinen asuu Kortepohjassa" -ohjelmasta versio, jossa nimi, osoite ja puhelin on esitelty vakioina.

 

Vakiomäärittelyä voitaisiin käyttää esimerkiksi kokonaislukuvakioiden määrittelemiseen:

 

 

 

Muuta edellistä ohjelmaa siten, että tulostetaan samat asiat tetraedristä.