Kokeen arvosteluperusteet

Jos kokeesi arvostelussa oli jotain epäselvää ota suoraan yhteyttä sen tarkistaneeseen ohjaajaan.

Tehtävä 1 (Tarkastaja: Valtteri)

a) Testaus 3p

Yksikkötestaus

Tutkitaan yksittäisten metodien ja luokkien toimintaa. Javassa yksikkötestaamiseen käytetään JUnit ohjelmistokehystä.

Integraatiotestaus

Tutkitaan komponenttien välistä yhteentoimivuutta. Erityisesti suunnitteluvaiheessa erillisten komponenttien välille määritetyt rajapinnat.

Järjestelmätestaus

Toiselta nimeltään hyväksymistestaus, joka testaa sovelluskokonaisuutta ja vertaa, että se toimii vaatimusdokumentin mukaisesti.

Regressiotestaus

Järjestelmän muutoksien jälkeen ajettavat testit, jotka varmisavat, että muutokset eivät riko mitään ehjää. Koostuvat usein kaikista edellämainituista testaustyypeistä.

0.75 pistettä per testaustaso, pyöristyy ylös lähimpään puolikkaaseen (esim 3 oikein on 2,5p). Jos testaustaso mainittu muttei selitetty, voi saada tästä 0.25p.

Yleisiä virheitä:

• Sekoitettu testaustasot yksikkötestien laatua mittaaviin mutaatio-/rivikattavuustesteihin, jotka siis testaavat testejä
• Sekoitettu testaustasoja keskenään
• Esimerkiksi integraatiotestauksen ja järjestelmätestauksen selitykset väärin päin. Tästä pieni pisterokotus.
• Alettu selittää betatestauksesta

b) Versionhallinta 2p

Versionhallintajärjestelmien ideana on pitää kirjaa käyttäjien tekemistä muutoksista ja luoda ns. "tallennuspisteitä" koodin tilasta tietyllä hetkellä (Git: commit).

Versionhallinnan hyötyjä:

• Eri käyttäjien muutoksia pystyy helposti tarkastelemaan, ja muutoksiin pystyy jättämään niitä kuvaavia viestejä (commit message)
• Tiedostojen eri versioita pystyy näppärästi vertailemaan toisiinsa, jotta näkee mikä on muuttunut
• Pystyy palaamaan helposti ajassa taaksepäin: jos löytyy esimerkiksi bugi, voi palata ajassa taaksepäin niin kauan kunnes bugia ei enää ja katsoa mikä on muuttunut
• Usea eri projektin parissa työskentelevä henkilö pystyy muokkaamaan samoja tiedostoja, versionhallinta huomauttaa konflikteista ja auttaa ratkaisemaan ne
• Haarautuminen (branching) mahdollistaa esimerkiksi prototyypin kasaamisen nykyisen version päälle ilman että "pääversioon" (main branch) tehdään muutoksia

Täydet 2 pistettä saa jos:

• Versionhallinta selitetty järkevästi
• Mainittu muutama (2-3) eri versionhallinnan hyöty (esimerkkejä yllä)

Yleisiä virheitä:

• Kysymys oli "Mitä versiohallinnalla tarkoitetaan, ja mitä hyötyä siitä on?". Kysymys ei siis suoranaisesti ollut Gitistä (vaikka vastauksen sai kyllä ihan vapaasti pohjata Gittiin), ja siksi muun muassa seuraavat usein esiintyneet aiheet menivät vähän ohi kysymyksen:
• Gitin komennot
• Gittiin tallennetun tiedoston eri tilat (working directory, staging...)
• Mainittiin vain yksi hyötykohde jota toistettiin
• Git esiteltiin pilvipalveluna. Git ei ole pilvipalvelu, vaan ihan lokaalisti omalla koneella käytettävä ohjelma, joka sisältää mahdollisuuden puskea lokaali repositorio etärepositorioon, kuten GitHubiin. GitHub ei siis ole sama asia kuin git.

c) Oliosuunnittelu 2p

Esimerkiksi seuraavat 4 ovat hyvin keskeisiä:

• Single responsibility principle eli luokilla tulisi olla vain yksi vastuu
• Program to an interface, not to concrete implementation, eli suosi rajapintoja
• Favor composition over inheritance, eli älä väärinkäytä perintää
• Tarpeettomien riippuvuuksien minimointi

1p per nimetty ja oikein selitetty oliosuunnittelun periaate, -0.5p jos jotain häikkää mutta kuitenkin sinne päin. Kaksi nimetty + selitetty oikein niin saa maksimin 2p.

Tehtävä 2 (Tarkastaja: Atte)

##a) (3p)

Paaohjelmaa ei ollut tarpeen kuvata. Mallivastauksen kompositiot (mustat salmiakit) sai korvata ykkösillä.

Täysiin pisteisiin:

• Mallivastauksen luokat mallinnettu
• Pääohjelmaa ei ollut tarpeen mallintaa.
• Suhteet (=viivat) luokkien välillä oikeat
• Kytkentärajoiteet oikein

Virheistä kaaviossa rokotettiin pisteitä tapauskohtaisesti. Yksi pienempi virhe ei välttämättä aiheuttanut pisteiden menetystä, mutta useampi pieni virhe laski jo pisteitä.

Yleisiä virheitä:

• Virheet kytkentärajoitteissa:
• Virheellinen kytkentärajoite. Näistä yleisin oli väite, että kuhunkin käyttäjään liittyy vain yksi arvio.
• Puuttuva kytkentärajoite
• Väärin päin (esim. merkitty että yksi arvio liittyy moneen kuvaan eikä toisinpäin)
• Virheet yhteyksissä
• Puuttuva yhteys (esim. arviosta käyttäjään)
• Väärä yhteys (esim. galleriasta arvioon)
• Yhteyden (tavallinen viiva) sijaan käytetty virheellisesti riippuvuutta (nuolellinen katkoviiva)
• Kuvagallerian ja käyttäjän/kuvan välinen yhteys merkitty niin, että sama käyttäjä-/kuvaolio voisi kuulua useampaan galleriaan. Tämä ei ole ohjelmakoodin perusteella kuitenkaan mahdollista.
• Komposition väärinkäyttö (ks. kurssimonisteesta milloin kompositiota saa käyttää).
• Paaohjelman ja Kuvagallerian välinen yhteys (vrt. riippuvuus).

##b) (4p)

Arvioiden hakemiseen ei tarvinnut käyttää looppia, kutsujen auki kirjoittaminen oli yhtä oikein.

Täysiin pisteisiin kolme vaihetta oltava mallinnettu:

• Galleriaolion luonti, käyttäjien rekisteröinti ja kuvan lataus (1p)
• Arvioiden lisäys (1,5p)
• 0,5p arvioiden luonnista
• 0,5p markon nimen hakeminen lisättäessä toista arviota
• 0,5p minnan nimen hakeminen lisättäessä toista arviota
• Arvioiden keskiarvon hakeminen
• 0,5p kutsuista galleriaan ja kuvaan
• 1p getArvio()-kutsuista kummallekin arviolle, loopilla tai ilman

Yleisiä virheitä:

• Erinäisiä syntaksivirheitä. Nuolet lähtivät väärästä paikasta tai päätyivät vääriin paikkoihin, metodikutsut väärin tai puuttuivat kokonaan ja saman luokan olioiden erottelemattomuus. Näistä sakotettiin tapauskohtaisesti virheen vakavuuden ja kattavuuden perusteella.
• Yleisin virhe oli Mapin ja Listin metodien esittäminen Käyttäjän, Kuvan ja Arvion metodeina, mistä sakotettiin 0,5p jos muuten oikein
• Virheet ja puutteet lisaaArvio()-kutsuissa, katso ylempää mitä tarvittiin kyseisen vaiheen täysiin pisteisiin.
• Alt/Opt/Loop väärinkäytetty, mutta muuten oikeat kutsut (-0,5p)
• Saman luokan olioita ei eroteltu mutta oikeat kutsut esiintyivät. (-0,5p)

Tehtävä 3 (Tarkastaja: Olli-Pekka)

Arvostelussa rokotetaan jos...

• mallivastauksessa olevat luokat eivät ole läsnä (osa voi olla parametreinä, mutta ei suositeltavaa).
• Yhteyksien luokkien välillä tulee olla oikein (on hyvä, että mallista näkyy, että kulttuurimatkaan liittyy aina ainakin yksi opastettu kierros, kuten tekstissä tarkennettiin!
• periminen on toteutettu kehnosti tai sitä ei ole ollenkaan.
• On selkeää, että jumppatuokio ja opastettu kierros ovat molemmat ohjelmia, eli niiden tulisi luokkina toteuttaa yläluokka Ohjelma (tai järjestetty ohjelma yms)
• kytkentärajoitteet puuttuvat tai ovat väärin.

Tehtävä 4 (Tarkastaja: Olli-Pekka)

Käyttötapausmallista saa täydet pisteet jos se on siististi piirretty noudattaen kurssilla esitettyjä käytäntöjä ja käyttötapauksen kulku on muotoiltu helposti luettavaan muotoon.

Arvostelussa rokotetaan jos...

• kaikki tarvittavat käyttötapaukset eivät ole sekä kaaviossa, että käyttötapausmallin tekstuaalisessa osassa.
• jokaiselle käyttötapaukselle ei ole merkitty selkeästi käyttäjiä ja esiehtoja (mainittu erikseen tehtävässä!).
• tekstissä esitetyt esiehdot eivät ole toteutuneet käyttötapausmallissa (esimerkiksi Kuskille ajopyynnön merkitseminen vaatii, että hän on "... tarpeeksi lähellä ja jonka tila on merkitty vapaaksi")