Harjoitustyö

1. Harjoitustyön aihe ja sisältö

Tärkein asia tässä harjoitustyössä on käyttöliittymän komponenttien käyttö. Erityisesti omien komponenttien tuottaminen ja jakaminen muiden käyttöön. Algoritmiset seikat eivät ole niin suurella painolla.

1.1 Aihe

Harjoitustyön aihe pitää keksiä itse. Se voi olla esimerkiksi jonkin aikaisemmin tehdyn ohjelman käyttöliittymän muuttaminen graafiseksi (vaikkapa Ohjelmointikurssin harjoitustyö, tosin tämä on ehkä työlästä), jokin peli tai mikä tahansa mieleenjuolahtava (tarpeellinen) aihe.

Aiheen virikkeeksi voi käydä katsomassa vanhoja harjoitustöitä.

1.2 Vaaditut ominaisuudet

Harjoitustyössä pitää olla tyypilliset Windows- ominaisuudet:

1.3 Lisäominaisuudet

Lisäksi mielellään osa seuraavista (jos aihe vain suo mahdollisuuden):

Eli laivanupotuspeli, joka on aina 10x10 ruudussa on huono aihe, mutta jos käyttäjä voi itse valita pelilaudan koon jostakin dialogista ja menusta, niin aihe onkin jo parempi.

1.4 Komponentit

Jokaisen harjoitustyössä pitää valmistua vähintään yksi yleiskäyttöinen komponentti (arpakuutio, pelikortti, korttipakka, pelilauta tms...), joka luovutetaan kaikkien kurssilaisten käyttöön dokumentoituna.

Kurssilla on postilista: gkoc04@korppi.jyu.fi, jossa on aluksi tarkoitus ilmoittaa mitä komponentteja oma harjoitustyö tulee sisältämään. Sitten kaikki ne, jolla on tarvetta moiseen komponenttiin, tekevät yhdessä mailina vaativuusmäärittelyn ko. Komponentille (esim. pitääkö arpakuutiossa olla 6 sivua, vaiko mielivaltainen määrä, pitääkö kuution kuvat olla käyttäjän valittavissa jne...).

Komponentit laitetaan WWW-sivuille sitten vapaasti levitettäväksi ja tarkoitus on että kurssilaiset käyttäisivät mahdollisuuksien mukaan myös muiden tekemiä komponentteja.

Komponentit tehdään mieluiten Delphillä (koska silloin niitä voi käyttää myös C++ Builderissä ). Javalla harjoitustyötä tekevät tekevät komponenttinsa luonnollisesti JavaBeans-komponenttimallin mukaan. Visual C++:lla voidaan käyttää MFC:tä tai wxWindowsia.

1.5 Dokumentointi

Harjoitustyöksi palautetaan dokumentoitu ohjelmalistaus. Osa dokumentointia on ongelman jakaminen selkeiksi ja hyvin nimetyiksi aliohjelmiksi. Samoin osa dokumentointia on epämääräisten vakioiden siirtäminen koodista tiedoston alussa oleviin vakiolausekkeisiin.

Koodit kannattaa dokumentoida jonkin dokumentointityökalun määritysten mukaisesti. Suositeltavia dokumentointityökaluja ovat DIPasDoc (Delphi), Doxygen (C++ ym.) ja Javadoc (kuuluu Javan kehitysympäristöön).

1.6 Turvallisuus

Ohjelma on tehtävä siten, että vaikka siinä käytetään osoittimia, ei niillä osoiteta oman alueen ylitse (esim. c: strcpy jne. on käytettävä erittäin harkitusti). Samoin vaikka ohjelma "toimisikin", saattaa se varata resursseja joita se ei vapauta ja näin ohjelman käynnistäminen useaan kertaan johtaa koko Windowsin tukkeutumiseen. Eli kaikki mitä varataan, pitää myös vapauttaa.

1.7 Julkisuus ja tekijänoikeus

Keskeneräiset ja valmiit harjoitustyöt ovat nähtävillä WWW:ssä myöhemmin esitettävällä tavalla. Tekijänoikeus on ilman muuta silti tekijällä ja hän voi muotoilla lähdekoodiinsa haluamansa tekijänoikeudet (esim. GPL).

2. Työkalut

2.1 Delphi, Visual C++ tai Java

Pääsääntöisesti jokainen tekee harjoitustyönsä Delphillä tai Kylixillä. Tällöin viestinkäsittelynä voidaan käytetään Borlandin VCL :ää tai CLX:ää. Mieluiten niin, että ifdef-lauseilla mahdollistetaan kumpi tahansa käännös.

Perustelluista syistä harjoitustyön voi tehdä myös Javalla (kehitysväline vapaa) tai Visual C++:lla.

Ohjelma pitää pystyä kääntämään ainakin 32-bittistä Windowsia varten. Samoin ohjelman käännöksessä EI SAA tulla yhtään virhettä eikä varoitusta (elleivät varoitukset johdu ulkopuolisesta koodista).

2.2 Aliohjelmakirjastot ja komponentit

Kurssilla jaetaan varsin suuri määrä aliohjelmia ja komponentteja eri tilanteiden käsittelyyn. Näitä saa vapaasti jokainen käyttää hyväkseen (alkuperäinen tekijä luonnollisesti mainittava).

Toisaalta omaan harjoitustyöhön saattaa tulla hienoja ominaisuuksia, jotka hieman modifioimalla kelpaisivat muillekin. Kaikki nämä pitää kirjoittaa omaksi komponenttikokoelmakseen ja dokumentoida siten, että muutkin voivat niitä käyttää. Hyvät komponentit liitetään sitten kurssin julkiseen aliohjelmahakemistoon.

Kurssin ja vakiokirjastojen ulkopuolisia (erityisesti avoimen lähdekoodin) komponentteja saa käyttää perustelluin syin - kuitenkin niin, että pääpaino on kurssin aikana kehitetyillä komponenteilla.

3. Aikataulu = TARJOUS

3.1 Sisältö

Koska erityinen toivomus opiskelusta työelämään siirtyneiltä on se, että pitäisi opettaa myös suunnittelua ja aikataulussa pysymistä, niin jokainen laatii omasta harjoitustyöstään SIISTIN HTML-aikataulun, johon on kirjoitettu vähintään.

Muuten aikataulun muoto saa olla vapaa ja siinä jokainen voi yrittää käyttää graafista silmäänsä parhaansa mukaan. Fonttikoon ei kuitenkaan tarvitse olla normaalia suurempaa, eikä fonttien kovin eksoottisia. Kuitenkin Courier- fontin käyttö (muualla kuin ohjelmalistauksissa) osoittaa ettei ymmärrä tekstinkäsittelystä yhtään mitään.

Näitä aikatauluja luetaan kuten tarjouksia, eli tarjouksen pitää olla mahdollisemmin houkutteleva, jotta asiakas "ostaa" nimenomaan tämän tuotteen lukuisten vastaavien joukosta!

3.2 Tarjouksen palautus

Aikataulu tallennetaan samaan paikkaan kuin kurssin harjoitustyö nimelle tarjous.html. Kaikki tarjouksessa olevat kuvat yms. laitetaan samaan alihakemistorakenteeseen ja viitteen lisukkeisiin pitää olla suhteellisia.

3.3 Aikataulun ja harjoitustyön arvosteleminen

Aikataulun voi olla suunniteltu jokaisen omiin tarpeisiin ja opintoihin sopivaksi, ja siinä pysyminen sekä harjoitustyö arvostellaan osana kurssia. Liian löysä ja epätäsmällinen aikataulu sinänsä on jo negatiivinen ilman erittäin hyviä perusteita. Harjoitustyöstä saa hyvityspisteitä (max. 3) tenttiin.

3.4 Aikataulu palautettava huhtikuun loppuun mennessä

Harjoitustyön aiheen on oltava paikallaan (= toimiva URL Korpissa ja tarjous tehtynä) viimeistään 30.4.

3.5 Aiheen ilmoittaminen mailina ja alustava komponenttiluettelo

Jokainen ilmoittaa postilistalle aiheensa ja alustavan luettelon siitä, mitä komponentteja hänen työnsä tulee sisältämään. Tämän pohjalta kurssilaiset voivat sitten ruveta tarkentamaan komponenttimäärityksiä postilistan välityksellä. Samasta komponentista voi lopulta olla useitakin kilpailevia toteutuksia, kunhan komponenttien rajapinta saadaan sovittua samaksi.

3.6 Välivaiheiden näyttäminen

Harjoitustyö säilytetään Webissä (Ei Optimassa). Harjoitustyön URL-hakemistojuuri merkitään Korppi-järjestelmään. (esim. http://www.it.jyu.fi/users/vesal/gko/).

Välivaiheiden näytöissä ollaan mielellään henkilökohtaisesti paikalla selittämässä. Harjoitustöitä voi näyttää pääteohjausten aikana tai luentojen jälkeisenä aikana, tarvittaessa voidaan ottaa käyttöön myös ajanvarausjärjestelmä.

3.7 Ongelmista voi kysyä muulloinkin

On aivan ilmeistä, että tämän kurssin harjoitustyössä tulee erinäisiä ongelmia, joita ratkoessaan vain hakkaa päätään seinään ja meinaa vielä viivästyä aikataulusta. Kohtuullisen ongelma ratkaisuyrityksen jälkeen voi ilman muuta kääntyä aina ohjaajan puoleen, on sitä itsekin oltu vaikeuksissa (ja tullaan olemaan).

Aluksi kysyn joka tapauksessa, että onko tilannetta tutkittu debuggerilla, joten tämä kannattaa tehdä jo etukäteen. Samoin ongelma kannattaa yrittää paimentaa hyvin pienelle alalle. Näin voimme vähän nopeuttaa ongelman käsittelyä.

© Miika Nurminen ()
Alkuperäinen teksti: Vesa Lappalainen. MN päivittänyt kesän 2004 GKO-kurssia varten.
Tyylitiedosto © Tommi Lahtonen & Petri Heinonen.
Viimeksi päivitetty: 2004-04-03