Harjoitustyön tekeminen

Harjoitustyön tekeminen	1
1.	Harjoitustyön aihe ja sisältö	1
1.1	Aihe	1
1.2	Vaaditut ominaisuudet	1
1.3	Lisäominaisuudet	2
1.4	Komponentit	2
1.5	Dokumentointi	2
1.6	Turvallisuus	2
1.7	Jukisuus ja tekijänoikeus	2
2.	Työkalut	3
2.1	Delphi,  C++ - kieli tai Java	3
2.2	Aliohjelmakirjastot ja komponentit	3
2.3	C++/OWL/MFC, Java ja Delphi	3
3.	Aikataulu = TARJOUS	4
3.1	Sisältö	4
3.2	Tarjouksen palautus	4
3.3	Aikataulun ja harjoitustyön arvosteleminen	4
3.4	Aikataulu palautettava 3.10 mennessä	4
3.5	Aiheen ilmoittaminen mailina ja alustava komponenttiluettelo	4
3.6	Välivaiheiden näyttäminen	5
3.7	Ongelmista voi kysyä muulloinkin	5
4.	Ajanvaraus	5

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ä hakemistosta: N:\KURSSIT\WINOHJ\HTYOT.
1.2	Vaaditut ominaisuudet
Harjoitustyössä pitää olla tyypilliset Windows–ominaisuudet:
•	menut
•	About-dialogi
•	avustus
•	painonappeja
1.3	Lisäominaisuudet
Lisäksi mielellään osa seuraavista (jos aihe vain suo mahdollisuuden):
•	leikekirjan käyttö
•	DDE, OLE
•	optioiden kysyminen käyttäjältä
•	.INI –tiedoston tai rekisterin käyttö optioiden tallettamiseen

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.

Kurssille perustetaan postilista: gko@mit.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 ola 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ä).  

Löytyisikö vapaaehtoista komponentti-WWW-sivujen ylläpitäjää?
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.
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	Jukisuus 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,  C++ - kieli tai Java
Pääsääntöisesti jokainen tekee harjoitustyönsä Delphillä (äärimmäisessä hätätilassa joko C++ Builderillä tai OWL/MFC-kirjastolla, käsitellään pintapuolisesti ja vasta kurssin lopulla) tai Javalla.

Viestin käsittelynä voidaan käyttää joko
•	Borlandin VCL:ää
•	alkeellista switch –lausetta
•	kurssin mallialiohjelmaa tabhand.c
•	Borlandin OWL 2.0:aa (tai uudempaa, OWL 1.0 ei enää kelpaa)
•	Microsoftin MFC:tä

Ohjelma pitää kääntämään ainakin 32-bittistä Windowsia varten.  Samoin ohjelman käännöksessä EI SAA tulla yhtään virhettä eikä varoitusta (paitsi Borland C++ Builderilla MFC-projektia käännettäessä MFC:n h-tiedostoista tulevat varoitukset on pakko hyväksyä :-)
2.2	Aliohjelmakirjastot ja komponentit
Kurssilla jaetaan varsin suuri määrä aliohjelmia ja komponentteja eri tilanteiden käsittelyyn.  Näitä saa vapaasta jokainen käyttää hyväkseen.

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.  
2.3	C++/OWL/MFC, Java ja Delphi
Jokainen tekee ohjelmastaan myös rinnakkaisen "pikkuversion" (vain muutamia ominaisuuksia tai pelkkä runko) kaikilla otsikossa mainituilla työvälineillä.  Visual Basicsta voi ostaa itseopiskelupaketin ja luennolla sitä käsitellään tunnin verran myöhemmin syksyllä.  Jos itse työ on tehty Delphillä, silloin Delphi-versiota ei tietysti tarvitse tehdä uudestaan.  

Tavoitteena on että jokainen ainakin pienessä määrin tutustuu yleisimpiin työkaluihin ja erityisesti niiden tapahtuman käsittelyyn.  Näiden pikaversioiden toteuttamiseen on tarkoitus käyttää esim. Javalla max 1-2 h (ulkoasu oikean oloinen, kaikista napeista tulee ”Ei toimi”-dialogi,  About-dialogi toimii, ohjelmasta pääsee pois).  OWL tai MFC-version tekemiseen voi vierähtää muutama tunti, toivottavasti ei kuitenkaan 10 h enempää.  Nämä ”lisäversiot” kannattaa tehdä heti kun asia on pääteohjauksissa ja luennoilla käsitelty.
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.
•	oma nimi
•	lyhyt kuvaus aiheesta
•	5-10 kohtainen toteutusaikataulu päivämäärineen (esisuunnitelma ...  runko ... avustuksen kirjoittaminen ... lopullinen versio).

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 ohjelma listauksissa) 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 lähetetään osoiteeseen vesal@mit.jyi.fi mailina joko liitetiedostoina (ei pakkauksia, ht:n aiheen mukaan kunnolla valmiiksi nimettynä, kaikki viittaukset suhteellisina) tai URL-listana viestin tekstiosassa. Tiedostot pitää todellakin nimetä huolellisesti, sillä jos kuvan nimi on kuva1.gif, niin voitte vaan arvata monellako muulla on samanniminen kuva kun talletan kaikki tarjoukset samaan hakemistoon.

Tarjous saa sisältää VAIN YHDEN .html-tiedoston.  Jos lisälinkkejä tarvitaan, niin ne laitetaan tekijöiden kotisivuille.

Tiedostot kopioidaan yhteen ainoaan hakemistoon kurssin sivuille 
http://www.mit.jyu.fi/~vesal/kurssit/winohj/htyot/gko00/  joten viittausten suhteellisuuteen ja nimien kuvaavuuteen kannattaa kiinnittää huomiota.
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 -3 - +3 pistettä.  Liian löysä ja epätäsmällinen aikataulu sinänsä on jo negatiivinen ilman erittäin hyviä perusteita.
3.4	Aikataulu palautettava 3.10 mennessä
Harjoitustyön aihe on palautettava viimeistään tiistaina 3.10. 
3.5	Aiheen ilmoittaminen mailina ja alustava komponenttiluettelo
Heti kun postilista on saatu valmiiksi, ilmoittaa jokainen 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, kunha komponenttien rajapinta saadaan sovittua samaksi.
3.6	Välivaiheiden näyttäminen
Harjoitustyö säilytetään Webissä.  Tästä on erillinen ohje:
http://www.mit.jyu.fi/~vesal/kurssit/winohj00/htnaytto.html   

Välivaiheiden näytöissä ollaan mielellään henkilökohtaisesti paikalla selittämässä.
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ä.
4.	Ajanvaraus
Jotta jokaisella voidaan taata kohtuullinen aika työn käsittelyyn, on parasta varata etukäteen aika.  Viikottainen varauslista on Kuukkelissa (http://www.mit.jyu.fi/kuukkeli/) (Paikka Agora C434.2).  Muistakaa perua aika jos ette jostain syystä käytäkään sitä.

Pikakysymykset voi tehdä ilman ajanvarausta tai jopa jos saa käytävällä hihasta kiinni.