Ohjelmointi 2 / Harjoitustyön teko-ohjeet 2024

HUOM! Gitiin laitettavien kuvien koko ei saa olla yli 0.1 MB/kpl Vesan koko malliharjoitustyö KAIKKINE kuvineen ja Java-koodeineen on 1.6 MB. Sellaisissa rajoissa pitäisi pysyä. Jos olet tehnyt liian isoja, niin pienennä näillä ohjeilla!

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: tuntiopettajilta

HT-ohjausten paikka: Etäohjaukset Zoomissa, lähiohjaukset: 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 Gittiin.

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 viime tinkaan 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ä.

  • Muista joka vaiheessa tehdä Gitiin branch: Git yleisesti-ohjeen mukaan. Ja muista yksittäisen vaiheen aikana commitoida useasti, niin hukkaat vähemmän :-)
  • Jos haluat lisätä ajat Google tai Outlook kalenteriin, niin luo uusi kalenteri "Internetistä" ja ota slla oleevasta kalenterista Edistynytja Vie kalenteri (ICS) ja pastea se kalenterin osoitteeksi.
# tarkeat

Please to interact with this component.

Calendar
# htaikataulu 
Myöhästyminen -0.5 pistettä/päivä (palautus pvm katsotaan Git-päivämäärästä)

Vaihe:  Aihe                           Valmis ja hyväksytty viimeistään
-------------------------------------------------------------------
1   Ohjelman toiminnan esisuunnitelma demoissa  
    HUOM! Suunnitelman tiedostot vaiheen 2 
    mallin mukaan (eli monta tiedostoa!).       ma   23.9.2024
-------------------------------------------------------------------
2   Suunnitelma hyväksyttynä ja käyttöliittymä  
    SceneBuilderillä tehtynä.                   pe   7.10.2024
-------------------------------------------------------------------
3   "Toimiva" kommentoitu ohjelma
    jossa on kaikki suunnitellut ikkunat        
    mutta toiminnoista tulee: "ei toimi".       pe  21.10.2024
-------------------------------------------------------------------
4   Tietorakenteet ja luokat                    
    suunniteltu ja hyväksytty                   pe  28.10.2024
-------------------------------------------------------------------
5   Tietorakenteet koodattu ja testattu.
    Ohjelma ilman muuta oikeaoppisesti
    jaettuna osiin ja kommentoitu sekä         HUOM! ALOITA AJOISSA!!!
    testattu.                                  n. 11.11.2024 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  18.11.2024, 105% porukoille pe 18.11.2024
-------------------------------------------------------------------
6   Ainakin toimiva tiedoston luku
    ja tiedostoon talletus.
    Viimeistään nyt tietorakenteet
    toimivat ohjelman käyttöliittymän           
    kanssa.                                     pe   2.12.2024
-------------------------------------------------------------------
7   Toimiva ja dokumentoitu ohjelma.            
    Ohjelmasta voi puuttua ohjaajan             
    kanssa sovittuja toimintoja.                pe  20.12.2024
-------------------------------------------------------------------

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.

Onko tämä ohjeistus 2011 kurssilaisille vielä 2024 relevantti?

VL: Jos tarkoitat tuota "Varoituksen sana", niin sekin kuten muutkin :-)

— 12 Jan 24 (edited 12 Jan 24)

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 (TIMistä) avulla vähintään päivää ennen ohjausaikaa. Jos et pääse paikalle varaamanasi ohjausaikana, peru se (jos TIM 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 gitissä: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.

Yksi tietorakenne tehdään taulukkojen avulla. Saanko kuitenkin tehdä samaan luokkaan getterimetodin joka palauttaa esim. arraylistin? Eli jos tietorakenne on täysin hoidettu taulukolla mutta tarvitsen joka tapauksessa myöhemmin esim. TableViewtä varten listoja, kuinka aikaisin saan muuntaa taulukon listaksi?

VL: Jos sisäinen toteutus olisikin listalla, niin olisin varovainen etten sitä listaa antaisi kenellekkään, koska silloin menetetään kontrollis siitä, kuka lisäilee ja poistelee, Sinne vaan metodi joka palauttaa toisen listan, jolla sisältöä voi näyttää, mutta ei muuttaa. Toki JavaFX:n tavoilla tehdä asia on iso houkutus antaa se sisäinen lista käyttöön, mutta sitten koodi toimisi vain JavaFX:n kanssa ja meillä on tavoite että se katkoviivan toinen puoli on täysin riippumaton JavaFX:stä.

Ahaa. Eli voin palauttaa jonkun listatyypin kunhan sen alkiot syntyvät oman taulukkototeutuksen kautta? Ja pitää olla viitteiden kanssa niinkin tarkka että sen näytettäväksi palautetun listan alkiot ovat klooneja eri viitteillä ja kaikki muokkaukset alkioihin menevät niiden rajapintaluokkien läpi? Täytyy tehdä hyvät find ja equals metodit näköjään.

VL: No tuon sää valitset itse että pitääkö niiden olla klooneja vai dokumentoitko käytön niin että minkä verran niitä saa muuttaa. Malliohjelmassa muokkaus tehdään kloonini ja jos se hyväksytään, se korvaa alkuperäisen. Moneen kohti riittävä voisi olla sellainen, että Jasenelle olisi immutable rajapinta ja sitten sinne listan typpinä on niitä rajapintaolioita, jolloin sen listan avulla ei voi helposti (valitettavasti typecastilla voi kiertää) muutella niitä olioita. Ison määrän kloonien teko ei kuitenkaan tunnu tehokkaalta.

— 04 Mar 24 (edited 04 Mar 24)

4. Harjoitustyön vaiheet ja niiden vaatimukset

Harjoitustyö tehdään aikataulun mukaan.

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

Oman harjoitustyön suunnitelmaa dokumentoidaan TIMin suunnitelmasivulle

Huomaa että vaiheissa 1 ja 2 ei edellytetä mitään Java-koodia tai muuta sellaista.

4.1 Esisuunnitelma (dl: 23.9.2024)

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).

Käyttöliittymän luonnosten lisäksi kannattaisi laittaa tallennustiedostojen esimerkkidataa versiohallintaan erilliseen hakemistoon

kelmit/harrastukset.dat
kelmit/nimet.dat
kuvat/paaikkunak.png
kuvat/avaak.png (huomaa kelmit)

koska esimerkkidataa tulee näkyä käyttöliittymän hahmotelmissa (ht1), SceneBuilderista otetuissa kuvakaappauksissa (ht2), tietorakenteen kuvassa (ht4), luokkarakenteen yksikkötesteissä (ht5) ja lopulta tiedoston käsittelyssä (ht6).

# ohje

4.2 Käyttöohje tai suunnitelma (dl: 7.10.2024)

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
  • GIT-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ä:

Suosittelen käymään SceneBuilder-tutoriaalin läpi, siitä on paljon apua. Linkki löytyy yläpalkista Työkalut > JavaFX > SceneBuilder.

— 16 Jan 24
# kayttoliittyma

4.3 Ohjelman käyttöliittymä (dl: 21.10.2024)

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 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 02 Feb 23)
# c1

KerhoGUIController.java

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

KerhoGUIController.java

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):

# c2

KerhoGUIController.java

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

KerhoGUIController.java

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 käyttää kontrolleria kuten esim Vaihe 3:n mallissa on tiedostossa fxKerho/KerhonNimiController.java.

— 09 Feb 19 (edited 03 Feb 23)

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

# c3

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     }

KerhoGUIController.java

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

Vaatimukset vaiheessa 4:

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.

Ensisijaisesti suositellaan käytettäväksi kurssille tehtyä vars.js-työkalua (ks. em linkki).

Kuvan voi tehdä myös 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ä TIMissä myös 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. Etäohjauksissa ei tarvitse olla 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.

Luennolla näytetään, että CRC-kortteja pääsee lisäilemään TIM-sivulle valitsemalla edit paragraph - Plugins - Ohj2 - CRC-kortti. Minulla ei valitettavasti Plugins-kohdassa ole Ohj2-kohtaa enkä löydä muistakaan kohdista CRC-kortteja. Miten saisin tämän lisättyä?

VL: Nyt on lisätty tuo myös syksy 22 menuun.

— 20 Oct 22 (edited 20 Oct 22)

IDEA tuputtaa recordia joidenkin luokkien tyypiksi ja sitä tarkasteltuani totesin että osa työstä voisi olla vältettävissä. Onko recordin käyttö sallittua vai onko ennemmin sellainen jota käytettäisiin ylimääräisessä harjoitustietorakenteessa? Tuleeko asia kurssin aiheena käsittelyyn jossain vaiheessa?

VL: Kaippa sitä saat käyttää jos haluat, se on lyhenne (tuli Java 14) luokalle, jossa on tietty määrä final attribuutteja ja niiden gettereitä. Kunhan ymmärrät mitä se tekee. Luokan pitää silloin olla immutable. Ks esim: https://docs.oracle.com/en/java/javase/21/language/records.html

— 10 Mar 24 (edited 10 Mar 24)
# vaihe5

4.5 Tietorakenteet ja luokat II (dl: 18.11.2024, 105% dl: 18.11.2024)

Pitääkö HT:n 5. vaiheessa myös muokkaamisen ja poistamisen toimia?

VL: Muokkaaminen vaatisi jo käyttäliittymää ja sen ei tarvite toimia ennen ht7. Poistaminen pitää joskus tehdä, viimeistään ht7, mutta ei tarvii ht5.

— 05 Mar 21 (edited 05 Mar 21)

Vaatimukset Vaihe 5.1 vähintään jompikumpi seuraavista:

  • Yksi tietorakennekuvan haara toteutettu käyttöliittymään asti: Jasen, Jasenet, Kerho ja Naytto kuten luento 14 (ks video)
  • Kaksi tietorakennekuvan haaraa toteutettu rekisteriluokkaan asti, ei käyttöliittymään asti: Jasen, Jasenet (oma tietorakenne), Harrastus, Harrastukset (Javan tietorakenne), Kerho, ei tarvitse näyttöä

Vaatimukset Vaihe 5:

  • käyttöliittymästä voidaan lisätä jäsenia ja edes viimeksi lisätylle (tai valitulle mallissa) harrastuksia ja ne saadaan "tulostettua" niin, että kun mennään tietyn jäsenen kohdalle, tulostuu hänen tiedot ja vastaavat harrastukset

Tässä vaatimukset 5.1 kohdassa Naytto ja Kerho hyperlinkistä aukeaa sama git -linkki. Pitäisikö vielä erikseen olla Naytto luokka, vai riittääkö Kolme ensimmäistä, kuten luennolla tehtiin?

VL: Siis v5.1 on joko Jasen-jasenet-Kerho-Näyttö tai Jasen-Jasenet-Harrastus-Harrastukset-Kerho. Vaihdoin tuon Naytto-linkin menemään sinne fxKerho-hakemistoon joka vastaa sitä ht3 vaihettu + luennolla tehdut muutokset jotta voi lisätä ja näyttää jäseniä.

— 25 Feb 21 (edited 25 Feb 21)

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.

Kuuluuko toi Vaihe 5.1 105% suoritukseen? Entä onko se vain bonus vai pakollinen, kun kalenterissa lukee, että bonus vaihe5.1 ja täällä ei?

VL: Tämähän on joka tapauksessa tehtävä mentäessä kohti HT5 ja jos sitä ei näytä, niin jää ilman Bonus-pistettä :-)

— 01 Mar 24 (edited 01 Mar 24)

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).

# vaihe6

4.6 Tiedostonkäsittely ja luokkien välinen yhteistyö (dl: 2.12.2024)

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).

# vaihe7

4.7 Toimiva ohjelma (dl: 20.12.2024)

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.

ei oo oikeuksia nähdä näitä 7-vaiheen malliharkkatöitä?

VL: kerrotko tarkemmin mitkä linkit eivät toimi?

Nämä kaikki kohdan 4.7 Toimiva ohjelma: malli: vaihe 7.1 malli: yksinkertainen vaihe 7.1 malli: vaihe 7.2 malli: vaihe 7.3 malli: vaihe 7

Jännä että mulla ei näy nämä, jos allaolevalla kommentoijalla näkyy. Olen sisäänkirjautuneena ja kaikki muu kyllä toimii.

E: vielä lisähuomiona, että eipäs näy näköjään edellisten vaiheidenkaan koodit mulle nyt, pari viikkoa sitten on kyllä näkynyt esim. 6-vaiheen mallikoodit.

— 15 Apr 20 (edited 16 Apr 20)

Mulla toimii kaikki noista ja koodit yms. näkyy myös, mutta TIMin suunnitelmasivua ei ole oikeuksia nähdä, eli noita Suunnitelma + avustus TIMissä-kohtia jotka johtaa sivulle https://tim.jyu.fi/view/kurssit/tie/ohj2/2019k/ht/vesal4

VL: lukekaa noita pitkiä selostuksia ja katsokaa GIT-linkkejä tuossa olevasta taulukosta. Ne ptiäisi ainakin aueta ja ovat tuoreempia.

— 16 Apr 20 (edited 16 Apr 20)

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.