The page has been modified since the last reload. Refresh now?

There are {{ $ctrl.pendingUpdatesCount() }} pending paragraph updates.

Ohjelmointi 2 / Harjoitustyön teko-ohjeet 2019

Tästä dokumentista löydät perusosan Ohjelmointi 2 -kurssin harjoitustyön tekemiseen liittyvistä ohjeista:

  • perustietoja harjoitustyöstä
  • aikataulun
  • vihjeitä aiheen suunnitteluun
  • lisätietoja ohjauksesta
  • vinkkejä, yleisohjeita ja varoituksen sanoja
  • harjoitustyön vaiheiden sisällöt

Katso myös sisällysluettelo harjoitustyöhön liittyvistä sivuista

Jos jokin asia on epäselvää, kirjaudu TIMiin ja tekstikappaleen vasemmasta reunasta avautuvan kommenttityökalun avulla tee huomautus dokumentin marginaaliin. Tarvittaessa voit korjata tai täydentää dokumenttia myös itse :)

{}

1. Mikä on harjoitustyö?

Kurssilla opiskelijat tekevät harjoitustyönä ohjelman, joka on jokinlainen rekisteri, jonka vaikeustaso vastaa kurssin aikana malliohjelemana tehtävää kerhon jäsenrekisteriä.

Oman aiheen täytyy kuitenkin olla erilainen – ideoita ja malleja saa toki poimia, mutta älä kopioi.
Aihe voi olla esimerkiksi opettajilla jokin opetusohjelma, urheilijoilla jokin pistelasku tai päiväkirja, koti-isillä reseptivarasto jne. Pohdi millaiselle ohjelmalle itselläsi tai läheiselläsi olisi käyttöä - auttaa paljon kun sinulla on jonkinlainen käsitys käyttökohteesta. Voit pyytää myös ohjaajilta apua ideasi rajaamiseen niin, että vaatimustaso on sopiva.

Kurssin harjoitustyö ei ole pohjimmiltaan työnäyte, vaan harjoitus ja oppimistilaisuus, jossa opiskelija yrittää omaamansa tiedon pohjalta tehdä jotakin.

Ryhmässä vai yksin? Harjoitustyö on hyvä tehdä ryhmätyönä, mielellään pareittain. Ryhmäläisillä voi olla kaikilla joko sama aihe jota he tekevät yhdessä tai sitten kullakin oma aihe, jota yhdessä voidaan työstää. Esimerkiksi yhden tekemät aliohjelmat kelpaavat muillekin, yksi ymmärtää ja selostaa muille. Kaikki voivat testata toistensa suunnitelmia ristiin. Erillisissä töissä on se etu, että jonkin ryhmäläisen lopettaessa voidaan työ saattaa yksin loppuun. Katso myös kurssin metaryhmät, jotka voivat hyvin työstää ideoita yhdessä.

HT-ohjaukset. Ideana on, että opiskelija esittelee kehittyvää harjoitustyötään ohjaajalle, joka sitten tutkii mikä työssä toimii ja mikä kaipaa korjaamista. Samalla tarkastellaan myös työtapoja ja pyritään jo varhaisessa vaiheessa saadaan koppi “huonoista tottumuksista”. Harjoitustyötä kannattaa käydä esittämässä ohjaajille riittävän usein ja avoimin mielin: “Punakynämerkinnät” eivät ole häpeäksi vaan hyviä vinkkejä siitä mihin kannattaa kiinnittää huomiota.

Alempana on lisää ohjeita ohjauksiin osallistumista varten.

HT-ohjausten varaus: Korpista

HT-ohjausten paikka: Vesa Lappalainen Ag C418.3, muut ohjaajat Ag C417.1 tai pääteohjausluokat pääteohjausten yhteydessä

Aiheiden ja harjoitustyön vaiheiden hyväksyminen. Harjoitustyön vaihe (alempana lisää) on hyväksytty, kun vaihe on näytetty henkilökohtaisesti ohjaajalle ja ohjaaja on merkinnyt hyväksynnän Korppiin. Tämä siis tehtävä aina ennen alempana kuvatun aikataulun takarajoja - kukin vaihe kannattaa siis esitellä ennen deadlinea, jotta ehdit tehdä myös mahdolliset korjaukset.

Harjoitustyön vaihe katsotaan ajoissa suoritetuksi, mikäli se on laitettu versionhallintaan ennen määräaikaa. Jos ohjaaja on pyytänyt tekemään korjauksia ja ilmoittamaan tehdyistä muutoksista sähköpostitse, tulkitaan sähköpostin lähettämisajankohta palautusajankohdaksi. Ohjaaja ei siis välttämättä ole merkinnyt vaihetta hyväksytyksi määräaikaan mennessä, vaikka palautus on tapahtunut ajoissa. Ota huomioon että ohjaajat työskentelevät osa-aikaisesti ja heillä on monta muutakin harjoitustyötä tarkastettavana. Ole ystävällinen äläkä turhaan hoputa ohjaajia, se ei nopeuta yhtään työsi hyväksymistä.

Kun vaihe on hyväksytty, tehdään siitä versionhallintaan tägi: NettiDemoWWW:hen vaihe.

Aikataulun suhteen poikkeuksen tekee Vaihe 1, jolle on annettu enemmän aikaa näyttöön (ks. Demo 1) ohjaajakapasiteetista riippuvista syistä.

{}
{}

2. Aikataulu

{}

Harjoitustyön vaiheet on esitelty hieman alempana. Tässä näet aikataulun.

Yritä tehdä työtäsi etuajassa. Huomaat nopeasti, että kurssi on raskas ja viimetinkaan jättäminen luo turhaa stressiä. Aikataulun takarajat ovat takarajoja ja niitä noudattamalla olet pahasti jäljessä siitä, missä luennoilla ollaan menossa. Aloita oman vaiheesi tekeminen heti kun asiaa on käsitelty luennoilla. Silloin työmäärä on pienempi ja pysyt kärryillä.

Myöhästyminen -0.5 pistettä/päivä

Vaihe:  Aihe                           Valmis ja hyväksytty viimeistään
-------------------------------------------------------------------
1   Ohjelman toiminnan esisuunnitelma demoissa  
    HUOM! Suunnitelman tiedostot vaiheen 2 
    mallin mukaan (eli monta tiedostoa!).       
    Vaiheen tulisi olla valmis annettuna        
    päivämääränä, mutta poikkeuksellisesti sen  
    voi hyväksyttää pe 18.1. asti.              ma  14.1.2019
-------------------------------------------------------------------
2   Suunnitelma hyväksyttynä ja käyttöliittymä  
    SceneBuilderillä tehtynä.                   pe  1.2.2019
-------------------------------------------------------------------
3   "Toimiva" kommentoitu ohjelma
    jossa on kaikki suunnitellut ikkunat        
    mutta toiminnoista tulee: "ei toimi".       pe  15.2.2019
-------------------------------------------------------------------
4   Tietorakenteet ja luokat                    
    suunniteltu ja hyväksytty                   pe  22.2.2019
-------------------------------------------------------------------
5   Tietorakenteet koodattu ja testattu.
    Ohjelma ilman muuta oikeaoppisesti
    jaettuna osiin ja kommentoitu sekä         HUOM! ALOITA AJOISSA!!!
    testattu.                                  n. 1.3 saisi olla vaihe 5.1    
    Mielellään myös käyttöliittymä                +1 bonuspiste jos valmis
    jossa toimivat tietorakenteet               
    ja kaikki toiminnot mukana,                 
    toimintojen alakohtien ei vielä             
    tarvitse toimia.                            pe  22.3.2019, 105% porukoille Korpin mukainen to 14.3.2019
-------------------------------------------------------------------
6   Ainakin toimiva tiedoston luku
    ja tiedostoon talletus.
    Viimeistään nyt tietorakenteet
    toimivat ohjelman käyttöliittymän           
    kanssa.                                     pe   5.4.2019
-------------------------------------------------------------------
7   Toimiva ja dokumentoitu ohjelma.            
    Ohjelmasta voi puuttua ohjaajan             
    kanssa sovittuja toimintoja.                pe  26.4.2019
-------------------------------------------------------------------

Eikö DL koskekaan ohjaajia? Palautin korjatun 2.vaiheen ohjaajalle aamupäivällä 30.1. mutta ohjaaja ei ole sen paremmin hyväksynyt työtä kuin ilmoittanut puutteistakaan. Olisi kiva tietää missä mennään.

01 Feb 19

Niin kauan kuin olet tehnyt ohjaajan pyytämät muutokset deadlineen mennessä, niin sinulla ei ole hätää myöhästymismiinuksesta (merkitsen ainakin itse suorituksen sille päivälle, jolloin olet tehnyt korjaukset). Meillä ohjaajillakin on myös muita kiireitä, kymmenittäin harjoitustöitä tarkistettavana ym. joten sähköpostitse palautettujen korjausten tarkistamiseen voi mennä muutama päivä.

01 Feb 19

DL koskee etenkin opiskelijoita. Eihän muillakaan kursseilla DL tarkoita sitä, että opettajat tai ohjaajat ehtivät tarkistamaan työn välittömästi, kun opiskelijat ovat sen palauttaneet. Harjoitustyön vaiheen hyväksymispäiväksi merkataan kuitenkin sähköpostin saapumispäivä, ei tarkistuspäivä.

01 Feb 19
{}
{}
{}

3. Vaatimuksia ja tärkeitä asioita

Harjoitustyön vaiheet on selitetty alempana. Suo kuitenkin ensin muutama hetki erinäisten suositusten lukemiselle…

3.1 Harjoitustyön vaatimuksia

Harjoitustyössä pitäisi saada harjoiteltua seuraavat asiat:

  • ohjelman suunnittelu
  • käyttöliittymän suunnittelu ja toteutus
  • tietorakenteiden ja olioluokkien suunnittelu
  • ohjelman jako osiin (metodit, ohjelmamodulit)
  • tiedostojen käyttö
  • dynaamiset tietorakenteet (toteutuksen minimi: yksi itse, yksi valmis)
  • tietorakenteen läpikäyminen (haku, etsiminen, lajittelu)

Siis aihe tulisi valita siten, että siinä käsiteltävä aineisto pitäisi ohjelman käyttökertojen välillä tallettaa tiedostoon.

Aineiston tarpeen pitäisi olla niin suuri, ettei sille välttämättä osata sanoa ennakolta tarkkaa ylärajaa. Esim. kirjarekisterissä voi siis olla 5, 50 tai 5000 kirjaa.

Lisäksi aiheen tulee olla sellainen että tarvitaan vähintään 2 tietorakennetta. Älä kuitenkaan lähde tekemään liian monimutkaista, 3-4 on vielä ok, mutta 10 vaatii jo työmäärän, joka on kurssin puitteissa useimmille liikaa :-)

Tyypillisiä tällaisia ohjelmia ovat erilaiset rekisteriohjelmat, esim. mallina oleva kerhon jäsenrekisteri.

Varoituksen sana vuoden 2011 kurssilaisilta: Älä tee liian haastavaa suunnitelmaa. Käytettävä GUI-kirjasto aiheuttaa omat ongelmansa.

Huom. Älä laita harjoitustyön mallitiedostoihin mitään sellaista dataa, minkä et soisi näkyvän koko maailmalle. Kaikki nimittäin näkyy versionhallinnan kautta hakukoneille. Älä siis syötä harjoitusrekistereihin arkaluontoisia tietoja, henkilötunnuksia, oikeita nimiä tms.

{}

3.2 Mitä pitää pohtia harjoitustyötä tehdessä

{}

3.2.1 Ohjelman helppokäyttöisyys ja loogisuus

Ohjelman tulisi olla sellainen, että sitä osaa käyttää kuka tahansa. Ammattimaisempaan käyttöön tehty ohjelma voi sisältää vähemmän ohjeita kuin yleiseen käyttöön tehty ohjelma.

{}

3.2.2 Kuka käyttää ohjelmaa ja mihin?

Harjoitustyön tehtävän määritys on varsin epämääräinen. Jotta aiheesta saa järkevän, kannattaa ennen muuta jäsentämistä pohtia sitä, missä vastaavalla ohjelmalla olisi käyttöä.

Kuvitellaan esimerkiksi, että tehtävänä olisi tehdä ohjelma, jolla voidaan tutkia elokuvateatterin kävijöiden ikää ja sukupuolijakaumaa:

Missä tällaisella ohjelmalla olisi käyttöä? Tietysti elokuvateatterin johto voisi tämän perusteella valita mitä teatterissa kannattaa esittää ja milloin näytöksiä pidetään.

Mistä tiedot saadaan? Tiedot voitaisiin saada suoraan ovelta kävijöiden mennessä teatteriin. Mikro olisi ovella ja jokainen kävijä näppäilisi kysytyt tiedot koneeseen. Tällöin tämän osan ohjelmasta tulisi olla todella idioottivarman. Kun kaikki ovat menneet sisälle, kävisi teatterin johto jollakin salasanalla lopettamassa syötön ja ottaisi tarvitsemansa analyysin sekä tallettaisi tulokset tiedostoon myöhempää käyttöä varten!

{}

3.2.3 Yleisyys ja muutettavuus

Esimerkiksi tehtävänä naisten telinevoimistelun pistelasku. Telineet, niiden nimet ja niiden määrä täytyy olla jälkeenpäin helposti muutettavissa, koska tuskinpa muuten ohjelmassa on isoa ero siinä lasketaanko miesten vai naisten kilpailua.

{}
{}

3.3 Ohjaukset

Harjoitustyön ohjausta annetaan mielihyvin kaikille niille, jotka tulevat apua ja/tai ohjausta pyytämään.

Ohjaukseen tulee varata aika (Korpista) avulla vähintään päivää ennen ohjausaikaa. Jos et pääse paikalle varaamanasi ohjausaikana, peru se (jos Korppi ei anna perua aikaa, peru aika lähettämällä ohjaajalle sähköpostia). Vapaina aikoina saa toki käydä katsomassa, josko ohjaukseen pääsisi.

Ole ystävällinen ja valmistaudu ohjaukseen etukäteen:

  • Ryhmätyössä kaikki ryhmän jäsenet mukana ja ajoissa paikalla
  • Tarkistakaa etukäteen ettei työssäsi ole yleisiä vikoja
  • Ota mukaan alkuperäisen suunnitelma ja kuva tietorakenteesta
  • Varmista, että harjoitustyön kaikki tehdyt vaiheet sekä myös työn tekeillä oleva vaihe on NettiDemoWWW:ssä ohjeen mukaan
  • Koska saat neuvoja, poimi ne talteen - muistiinpanovälineet mukaan!
  • Pidä myös edellisten ohjauskertojen muistiinpanot mukana
  • Pohdi etukäteen mihin haluat kommentteja ja apuja
  • Ajan säästämiseksi (ohjaajilla on kädet täynnä ja oven takana seuraavat jonossa) ottakaa välineet ja dokumentit esille jo ennen huoneeseen saapumista

Ohjauksessa:

  1. ei ole mitään pelättävää :)
  2. esitettävä kritiikki ja korjausehdotukset on tarkoitettu positiiviseksi opetukseksi
  3. kirjoitetaan muistiin oma-aloitteisesti ohjaajan esittämät muutokset
{}

3.4 Kirjoitustyyli ja kommentointi

Kirjoita heti koodia ja kommentteja mahdollisimman oikealla tyylillä!

Kun kirjoitat harjoitustyötä, käytä heti oikeaoppista sisennystä, muuttujien nimien valintaa yms. – ei kannata oikaista kirjoittamalla ensin “sotkua” ja sitten tuhlata myöhemmin aikaa koodin siivoamiseen.

Harjoitustyö kirjoitetaan ja kommentoidaan samaan tyyliin kuin monisteen loppuosassa esitetyt esimerkkiohjelmat. Myös muut selkeät ja perustellut tyylit käyvät.

Erityisesti harjoitustyöstä tarkastetaan:

  • kommenttien riittävyys
  • muuttujien nimien käyttö ja kuvaavuus
  • mikäli käytetään sellaisenaan kurssin esimerkkiohjelmia, on se ok. Mikäli niitä muutetaan, on kommentoitava mitä on muutettu.
  • sisennysten loogisuus (4 välilyöntiä/sisennys riittää, mutta tärkeintä on yhtenäinen tyyli)
  • vakioiden käyttö, eli ohjelmakoodissa ei saa esiintyä hämäräperäisiä numeerisia tai tekstivakioita, joita joskus mahdollisesti voisi joutua muuttamaan
  • viitteiden oikea käyttö
  • ohjelma kääntyy täysin ilman varoituksia tai virheitä
  • tietojen syöttö toimii
  • ohjelmassa on vähintään joitakin oikeellisuustarkistuksia
  • ohjelmassa on jonkinlainen avustus
  • ohjelmassa on toteutettu itse vähintään yksi tietorakenne taulukkojen avulla
  • ohjelmassa on vähintään yksi tietorakenne tehtynä Javan ArrayList tms. luokalla
  • ohjelmassa on toteutettu vähintään yksi tietorakenteen läpikäynti (“etsiminen”) ja mielellään esim. Javan algoritmien avulla toimiva lajittelu

Huom. Jokainen ohjelmaan kirjoitettu rivi pitää pystyä perustelemaan ja ymmärtämään - jos vain copy-pasteat koodia sieltä ja täältä, tämä on vaikeaa.

{}

4. Harjoitustyön vaiheet

Harjoitustyö tehdään aikataulun mukaan.

Ohjelman koodin kehityksen vaiheet näet: Vesan malliharjoitustyöstä

Oman harjoitustyön suunnitelmaa dokumentoidaan TIMin suunnitelmasivulle

{}

4.1 Esisuunnitelma

Harjoitustyön 1. vaihe on esisuunnitelman laatiminen. Tässä vaiheessa on tarkoitus tutkia tehtävän määritys tarkemmin ja yrittää määritellä siitä minkälainen ohjelman tulisi olla. Erityisesti mietitään kaikki ne kohdat, joita näyttöön tulostuu, mitä käyttäjä vastaa ja miten ohjelman tulisi eri vastauksiin reagoida!

Huom. Koska Kerho-ohjelma luodaan kurssilla malliohjelmana, saattaa ohjaaja tehdä suunnitelmaan muutoksia tai lisäyksiä. Oma työsi ei synny pelkästään vaihtamalla malliohjelmassa sanoja Kerho sanoiksi Kauppa ja sanoja Jäsen sanoiksi Tuote.

Vinkiksi myöhempää varten: Käyttöliittymä kannattaa ohjelmointivaiheessa eristää muusta koodista, jotta käyttöliittymän vaihtaminen olisi helpompaa (vrt. kerho -malliohjelmat).

{}
#

4.2 Käyttöohje tai suunnitelma

Harjoitustyön 2. vaiheen tavoitteena on, että:

  • päivitetään omalle suunnitelmasivulle suunnitelman vaihe 2
  • ohjaajan edellisessä vaiheessa ehdottamat muutokset on tehtynä suunnitelmaan
  • käyttöliittymäkuvat on piirretty suunnitelmatyökaluilla (pääosin SceneBuilderilla)
  • kuvia todennäköisesti pitäisi olla enemmän kuin vaiheessa 1
  • suunnitelmaa on tarkennettu ja se on kirjoitettu puhtaaksi
  • svn-versionhallintaan on siirretty myös tarvittavat projektitiedostot kts. harjoitustyön näyttö

Eli nyt pitäisi olla kirkkaampi kuva siitä mitä olla tekemässä. Periaatteessa kenen tahansa pitäisi nyt suunnitelman perusteella ymmärtää mitä ohjelma tekee ja miten sitä pääpiireittäin käytetään.

Jatkossa ohjelmaa kehitetään tämän suunnitelman pohjalta. Luonnollisesti tarkennuksia ja muutoksia voidaan tehdään sitä mukaan kun opitaan ja ideoidaan uutta. Muutokset on syytä näyttää aina ohjaajalle!

Katso missä pisteessä Vesan kerho-esimerkin suunnitelma on vaiheen 2 kohdalla:

Muita aiheeseen liittyviä:

{}

4.3 Ohjelman käyttöliittymä

Tässä vaiheessa toteutetaan ohjelman käyttöliittymä.
Tarkoitus olisi että kaikki 2. vaiheen aikana piirretyt ikkunat tulisivat jostakin näkyville. Eli “asiakas” voisi katsella ja kokeilla “toimivaa” prototyyppiä. Mitään varsinaista datan kanssa toiminnallisuutta ei tarvitse olla, mutta jokaisen käyttöliittymäkohdan tulee reagoida jollakin tavalla.
Esimerkiksi avaamalla toinen dialogi (joka tehty 2. vaiheessa) tai jos pitäisi tulla varsinaista toiminnallisuutta, jota ei ole järkevä vielä toteuttaa, tuomalla näyttöön viesti: “Ei toimi vielä!”. Tässä voi olla käyttää valmiita dialogeja (ks. Dialogs).

Vaiheen tarkoitus asiakkaan ilostuttamisen lisäksi on se, että ohjelmoijalle tulee valmis runko, jossa jokainen aliohjelma on valmiiksi paikallaan (mutta tuottaa ehkä tuon “Ei toimi vielä!”). Sitten jatkossa aliohjelmia voi lähteä täydentämään toimivaksi yksi kerrallaan.

Eli tapahtumankäsittelijät ovat tyyliin:

Pitääkö jar tehdä vain pää-main tiedostosta vai kaikista. Minulla on kolmosvaiheessa tehtynä 3 fxml, 3 controller ja 4 main tiedostoa.

VL: vaiheessa 3 on enää yksi ohjelma, joten yksi jar, eli ohjelma joka käynistelee niitä muita dialogeja. Vrt vaiheen 3 malliohjelma.

13 Feb 19 (edited 13 Feb 19)
{}
#

KerhoGUIController.java

082     @FXML private void handlePoistaJasen() {
083         Dialogs.showMessageDialog("Vielä ei osata poistaa jäsentä");
084     }

Lisäsin fxml-tiedostoon toiminnon lisääUusiKasvi ja controller tiedostoon aliohjelman, joka näyttää sitä kutsuttaessa viestin "ei toimi", mutta kun yritän käynnistää ohjelmaa, tulee virheilmoitus "javafx.fxml.LoadException: No controller specified.". Mistähän se johtuu?

10 Feb 18 (edited 11 Feb 18)

Nyt toimii, en ollut laittanut fxml-tiedostoon kontrolleria, eli ensimmäisen rivin BorderPanen loppuun esim fx:controller="fxKerho.KerhoGUIController"

11 Feb 18
{}

ja vastaavasti (esimerkki harrastusten poistamiselle):

{}
#

KerhoGUIController.java

097     @FXML private void handlePoistaHarrastus() {
098         Dialogs.showMessageDialog("Ei osata vielä poistaa harrastusta");
099     }

Jos on tehnyt käyttöliittymän suoraan scenebuilderilla eli siis ei projektin alla eclipsessä niin miten sen saisi tuotua uusi fxml-package työkalulla luotuun hakemistoon?

VL: luo kontrolleria varten normaalisti File/New/Class uuden Java-luokan, antaa sille fiksun nimen ja laittaa sen nimen FXML:än kontrolleri-kohtaan. Sitten täyttä kontrolleria kuten esim Vaihe 3:n mallissa on tiedostossa fxKerho/KerhonNimiController.java.

09 Feb 19 (edited 10 Feb 19)
{}

Modaalisen itse tehdyn dialogin voi näyttää tyyliin:

#

KerhoGUIController.java

107     @FXML private void handleTietoja() {
108         // Dialogs.showMessageDialog("Ei osata vielä tietoja");
109         ModalController.showModal(KerhoGUIController.class.getResource("AboutView.fxml"), "Kerho", null, "");
110     }

Huomattakoon, että ohjelma pitää olla aina kommentoitu. Erityisesti kukin tarvittava .java-tiedosto pitää varustaa tekijöiden nimillä ja teko- sekä muutospäivämäärillä!

{}

Linkistä “Vinkkejä CRC-korttien tekoon - kohta vaihe 4” ei löydy vinkkejä.

Pitäisi olla kun avaat sen ko kohdan tuosta alaluvusta.

19 Feb 19 (edited 19 Feb 19)

Ohjelman jatkokehittelyn kannalta on välttämätöntä kiinnittää ainakin jonkinlainen osa ohjelman tarvitsemista tietorakenteista. Tietorakenteista piirretään aluksi kuvat ja ne hyväksytetään ohjaajalla.

Mahdollisista piirto-ohjelmista on oma sivu.

Kuvan voi tehdä esimerkiksi Draw.io-Online -piirto-ohjelmalla tai Visiolla (löytyy mikroluokan Windows 10 -koneilta). Pohjan mallista löytää osoitteesta kerhohar.vsd. Pohja aukeaa myös uudehkoilla LibreOfficen versioilla, mutta ainakin Linuxilla pitää varmistaa, että libvisio-paketti on asennettuna.

Kuvan voi tehdä myös TIMissä Graphviz-ohjelmalla.

Tietorakenteiden ei välttämättä tarvitse olla samanlaiset kuin Kerho-ohjelmassa, mutta useisiin harjoitustöihin tämä rakenne käy lähes sellaisenaan tai pienin muutoksin.

Samalla suunnitellaan ohjelman luokkajako. Luokkajako kirjoitetaan CRC-korteille tai piirretään UML-luokkakaavioksi, jotka näytetään ohjaajalle.

Tämä vaihe kannattaa tehdä kunnolla ja ajatuksella! Aiemmilla kursseilla on havaittu, että jos tämän vaiheen tekee huolimattomasti, seuraava vaihe on yleensä yhtä vaikeuksien kanssa painimista.

Vertaa oikeata ja virheellistä kuvaa

Vaiheen 4 kuva pitää olla aina esillä ja pääteohjauksissa paperille tulostettuna.

Vaiheen 4 jälkeen katso aina kuvasta algoritmi mitä olet tekemässä, muista kurssin alkuosa algoritmeista. Jos ei 100% varmasti tiedä mitä haluaa tehdä, ei sitä voi tehdä Javallakaan.

{}

4.5 Tietorakenteet ja luokat II

Onko malli, jossa jäsenet ja harrastukset on liitetty erillisellä taululla, edelleen samanlainen kuin Swing-aikana?

VL: tuosta ei ole kukaan ehtinyt tehdä JavaFX-esimerkkiä. Tietorakenteen kuva on oikein ja koodikin silti osin, mikä ei koske käyttöliittymään.

12 Mar 17 (edited 25 Mar 17)

Seuraavaksi toteutetaan vaiheessa 4 suunnitellut tietorakenteet ja luokat. Toteutetaan yksittäisiä tiedonpaloja hallinnoivat luokat (vrt. Kerho-ohjelman Jasen ja Harrastus) ja testataan ne.

Tässä vaiheessa tulee jokainen luokka olla omassa Java-tiedostossaan ja kukin luokka sille sopivassa paketissa. Ohjelman täytyy olla hyvin kommentoitu: jokaisen luokan ja metodin tarkoitus ja käyttö tulee olla hyvin dokumentoitu kommenteissa.

Viimeistään tässä vaiheessa (ja myöhemmissäkin) ohjaajat tenttaavat suullisesti tekijän ymmärtävän jokaisen ohjelmaansa kirjoittaman lauseen merkityksen (oma listaus saa olla mukana ja siinähän täytyy olla kommentteja).

Esimerkiksi Jasen-luokan toteutus kirjoitetaan Jasen.java-tiedostoon. Toteutustiedostoon tehdään testit (ComTest tai JUnit), joilla luokan toimivuus voidaan testata. Seuraavaksi toteutetaan säiliöluokat (vrt. Kerho-ohjelman Jasenet) ja testataan ne. Esimerkissä Jasenet.java.

Tietysti toteutetaan esimerkissä myös vastaavat harrastuksiin liittyvät luokat. Lopuksi vielä luokat yhteen rajapintaa kapseloiva Kerho.java. Ainakin yksi tietorakenne pitää toteuttaa itse taulukkomaisesta rakenteesta (tai jostakin muusta itse tehdystä, esim linkitetystä listasta tai puusta) lähtien (vrt. Jasenet) ja ainakin yksi käyttäen Javan valmiita luokkia (vrt. Harrastukset).

Käyttöliittymän osalta riittää, että esimerkiksi toiminta vastaa malliohjelman tapaan tulosta-toiminto eli tulostetaan kaikki jäsenet ja heidän harrastuksensa tulostusikkunaan. Lisää Jäsen-nappi lisää yhden “Aku Ankan” ja lisää harrastus yhden harrastuksen aina vaikka viimeksi lisätylle jäsenelle. Tulostuksesta voidaan kokeilla että tämä toimii. Missään tapauksessa ei vielä tarvitse tietoja pystyä syöttämään. Jos rakenteita on enemmän, ei muiden tarvitse vielä toimia käyttöliittymästä (mutta saa toimia).

{}

4.6 Tiedostonkäsittely ja luokkien välinen yhteistyö

Tässä vaiheessa Kerho-ohjelman tapauksessa ohjelma osaa tulostaa jäsenet kunkin harrastusten kanssa, jäsenen lisäyksessä kysytään ja tallennetaan myös harrastukset.

Vaihe kannattaa aloittaa tekemällä esimerkin vaihe 5 mukainen luokkien välinen “yhteistyö” käyttöliittymäluokkaan kaikkien ohjaajan kanssa sovittavien tietorakenteiden osalta. Samoin viimeistään nyt on tietorakenteiden koon osattava kasvaa “rajattomasti”.

Seuraavaksi toteutetaan tiedostonkäsittely. Katso luentomonisteen luku 15. Tiedostot.

Ohjelma on paras rakentaa niin, että ohjelman käynnistyessä luetaan mahdollisesti olemassa olevasta tiedostosta tiedot ja ainakin sammutettaessa ne tallennetaan. Lienee helpointa toteuttaa ensin tiedostosta lukeminen ja testata se, ja sitten vasta tiedostoon tallentaminen ja testata se (tai päinvastoin).

Vaiheessa 6 pitää siis olla tiedostojen lukeminen ja kirjoittaminen sekä luokkien välinen “yhteistyö” käyttöliittymäluokan puolella (esim. osaa tulostaa yhden jäsenen kaikki harrastukset).

Luonnollisesti testit eri luokille (käyttöliittymälle ei tarvii).

Citation: <“tietorakenteiden koon osattava kasvaa “rajattomasti”> was interpreted by the supervisor as a necessity to upscale all data structures, including Array, while in example Kerho vaihe 6 no upscaling methods in”Jasenet" data structure. Although I will realize upscaling array method in my project, this point should be clarified for others.

VL: That is correct from superviser. In example this is not done so that everyone must find the code by them self.

22 Mar 19 (edited 26 Mar 19)
{}

4.7 Toimiva ohjelma

Nyt ohjelmaan täydennetään alkuperäisen suunnitelman mukaisia toimintoja pala kerrallaan koko ajan testaten. Näin saadaan lopuksi aikaan valmis ja toimiva ohjelma.

Harjoitustyössä ei välttämättä kaikkien alavalintojen tarvitse toimia, kunhan opiskelija on käynyt kaikki oleelliset ohjelmointiin ja käytettyyn kieleen liittyvät asiat läpi. Ohjaajan kanssa on sovittu edellisen vaiheen hyväksymisen yhteydessä mitkä kohdat ohjelmasta voidaan jättää toteuttamatta.

Toivottavaa olisi, että vähintään jokin yksinkertainen etsiminen (haku) toimisi, samoin lajittelu esimerkiksi Javan valmiita algoritmeja käyttäen.

Pääosin harjoitustyön tulee tasoltaan vastata luentomonisteen malliohjelmana olevaa kerhon jäsenrekisteriä ja sen tulee toimia alkuperäisen suunnitelman mukaisesti!

Tässäkään vaiheessa ei kannata matkia sokeasti kurssin malliohjelman toteutuksia, koska jokainen ohjelmassa oleva rivi pitää pystyä perustelemaan ohjaajalle.

Vaiheessa 7 täytyy siis olla valmiina ainakin seuraavat asiat (sovittava ohjaajan kanssa henkilökohtaisesti)

  • Tiedon lukeminen käyttäjän syötteistä (“lomakkeet”) joillakin oikeellisuustarkistuksilla.
  • Jokin etsiminen tai vastaava (esim. valikoiva listaus/tulostus), jossa koko tietorakenne täytyy käydä valikoiden läpi.
  • Jokin oma (selvästi itse tehty) toiminto malliohjelmaan nähden.
  • Kommentit ainakin jokaisen tiedoston alussa ja kunkin metodin alussa JavaDocin mukaisesti. Laittakaa kunkin tiedoston alkukommentteihin myös tekijöiden email, jos pitää olla yhteydessä.
  • Ohjelman käännöksessä ei saa tulla yhtään virhettä eikä varoitusta Vesan asetuksilla. Tätä ei pidä korjata siten, että viljelee kaikkialle SuppressWarnings-annotaatiota. Vain joihinkin kohtiin voi olla perusteltua laittaa se.
  • Tiedostojen alkukommenteissa on lueteltava ne asiat, jotka kustakin tiedostosta on tekemättä. Sen tiedoston alussa, jossa on pääohjelmakin tai suurin osa koodinkäsittelystä (mallissa esim. KerhoMain tai KerhoGUIController), on kerrottava, mitkä ohjelman osat eivät toimi.

These are the current permissions for this document; please modify if needed. You can always modify these permissions from the manage page.