Tentin mallivastaukset - mluukkai/OTM2012 GitHub Wiki

Tehtävä 1

a)

  • ohjelmistotuotantoprosessi sisältää 4 vaihetta: 1.5p
    • määrittely, suunnittelu, toteutus, testaus (+ylläpito)
    • mitä vaiheet pitävät sisällään:
    • erityisesti kerrottava vaatimusmäärittelyn rooli
    • suunnittelu: arkkitehtuuri+oliosuunnittelu, mitä ne ovat
    • testauksesta: yksikkö vs järjestelmä, mitä ne ovat
  • vesiputousmalli: peräkkäin: 0.5p
    • vaiheet tässä järjestyksessä
    • edellinen valmis ja hyvin dokumentoitu ennen seuraavaa
  • ketterä:
    • iteraatioissa: 0.5p
      • jokainen iteraatio tuottaa osan valmiista ohjelmistosta
      • jokainen iteraatio sisältää kaikki vaiheet
    • motivaatio: asiakaskommunikaation parantaminen: 0.5p
      • saadaan todennäköisemmin sitä mitä oikeasti halutaan

täydet: suunilleen kaikki yo. mainittu ja lisäksi hyvin kirjotettu johdonmukainen essee.

miinuspisteitä

  • yo oleellisten puuttumisesta
  • jos irrallisia “sisällykksettömiä” lauseita

HUOM: erityisen ansiokas ja sisällöltään hyvä ja omaperäinen kirjoitelma voi kompensoida jonkun “asian” puuttumisesta lähtevät pisteet

b)

  • oliosuunnittelun periaatteet 1p
    • ikiaikaisia periaatteita joiden noudattaminen edesauttaa koodin laajennettavuutta ja ylläpidettävyyttä
    • esimerkkejä, näitä tulisi olla ainakin kolme:
      • single responsibility eli luokan pitää …
      • favour compos over inheritance: eli mielummin …
      • program to interfaces not to concrete classes: eli älä riipu konkreettisista toteutuksista, vaan …
      • loose coupling: eli tee eri komponenteista löyhästi kytkettyjä
    • tulee selittää joka kohdassa miksi periaatetta kannattaa noudattaa/mitä sen noudattamattomuus aiheuttaa
  • koodihaju 0.5p
    • pintatason indikaatio huonosta koodista, helppo “nähdä päältä” että jotain mätää koodissa, perimmäinen syy voi olla kuitenkin syvemmällä, esim designissa
    • esimerkkejä: 0.25p
  • tekninen velka 0.5p
    • metafora sille, että joskus voi ja ehkä kannattaakin oikaista laadullisissa asioissa, syntyy kuitenkin “velkaa” joka pitää maksaa takaisin jos ohjelma osottautuu pitkäikäiseksi.
  • refaktorointi 0.5p
    • koodin sisäisen rakenteen muuttaminen sen toiminnallisuuden pysyessä samana
    • tarkoitetaan yleensä huonon koodin siistimistä
    • esimerkkirefaktorinteja 0.25p

täydet: suunilleen kaikki yo. mainittu ja lisäksi hyvin kirjotettu johdonmukainen essee

miinuspisteitä

  • yo oleellisten puuttumisesta
  • jos irrallisia “sisällykksettömiä” lauseita

HUOM: erityisen ansiokas ja sisällöltään hyvä ja omaperäinen kirjoitelma voi kompensoida jonkun “asian” puuttumisesta lähtevät pisteet

Tehtävä 2

a)

Luokkakaavio (Max. 3 pistettä)

malli2a

  • Kontaktiopetus ja tehtävä hyväksyttiin myös rajapintoina.
  • Oppimiskomponentti abstraktina luokkana hyväksyttiin.
  • Kurssin ja kontaktiopetuksen, kokeiden sekä tehtävien välisessä yhteydessä hyväksyttiin kompositiot, monen suhde yhteen kurssiin tai monen suhde moneen kurssiin.
  • Yksi tapa olisi ollut noudattaa myös laskuharjoituksien esimerkkiä, jossa kursseista tehdään erikseen kurssitoteutus.
  • Kurssilla ei välttämättä ole koetta, joten osallistumisrajoite on *.
  • Pajan ja pajatehtävien välillä ei ole yhteyttä. Pajat eivät rajoita sitä, mitä pajatehtäviä niissä tehdään.
  • Teoriatehtävän ja laskuharjoituksen yhteys ei ole yksi yhteen, silloin laskuharjoituksessa olisi vain yksi tehtävä. Yhteyden suunta on tekstin pohjalta epäselvä, joten se on jätetty merkitsemättä.
  • Pisteitä vähennettiin vääristä osallistumisrajoitteista, perinnän/rajapintojen puuttumisesta sekä puuttuvista luokista
  • Mallivastauksessa näkyviä attribuutteja ei vaadittu. Ne havainnollistavat esimerkkejä yhteisistä ominaisuuksista ja abstraktin luokan osuudesta.

b)

Tehtävänantoon oli jäänyt kaks virhettä: Samanniminen olio määritellään kahdesti ja asetaSaldo() puuttuu. Virheellisyyden vuoksi sekvenssikaaviossa saldon asettamisen puuttumista sekä ostos-olion käyttäytymistä katsottiin hieman sormien läpi.

Luokkakaavio (Max. 2p)

malli 2b luokkakaavio

  • Hyväksyttiin varastoon * tuotetta, vaikka koodissa varastossa on aina kaksi.
  • Mallivastauksessa pankista ei ole yhteyksiä. Tämä on hyväksyttävää luokkakaavioissa.
  • Ostoskorin ja ostoksen välillä hyväksytään kompositio. Koodi ei toisaalta kieltänyt saman ostoksen sijoittamista useaan ostoskoriin.
  • Main hyväksyttin luokkakaaviossa, jos se oli riippuvainen muista luokista.
  • Yleisin virhe oli unohtaa varaston ja tuotteiden välistä kompositio. Varasto luo tuotteet, joten tuotteilla on selkeä olemassaolo riippuvuus varastosta.
  • Suora yhteys Mainista muihin luokkiin on virhe.
  • Pankki ei käytä eikä tunne ostoskoria.
  • Yhteyksien suuntien puuttumisesta, vääristä suunnista ja vääristä yhteysrajoitteista vähennettiin pisteitä.
  • Jos piirsi vahingossa oliokaavion, saattoi saada puoli pistettä, mikäli oliokaavio oli selvästi oikein.

Sekvenssikaavio (Max. 4p)

sekvenssin malli

Tarkempi kuva: https://raw.github.com/mluukkai/OTM2012/master/mallivastaus_kuvat/sekvenssikaavio_malli.jpg

  • Looppien käyttö on aivan yhtä oikein kuin mallivastauksen tapa.
  • Pankin palautusarvon sai jättää merkkaamatta, sillä palautusarvoa ei tiedetä.
  • Yleisimmät virheet olivat puutteet varaston luonnissa tai hinnan laskemisessa
  • Tilinumeron tai määrän merkitseminen olioiksi laskettiin pieneksi virheeksi.
  • Pisteitä vähennettiin, jos metodikutsuja teki väärät oliot, palautusarvot oli merkitty väärin tai kokonaan merkitsemättä.
  • Pisteitä vähennettiin, jos ostoksen asettamisen ostoskoriin ja hinnan teki vain Maidolle. Jos toistuvuuden Oluelle mainitsi, riitti yhden käsittely.
  • Sekvenssikaavioissa on normaalia mallintaa olioita, jotka on luotu ennen sekvenssikaavion kuvaamaa tapausta, joten ostoskorin ja pankin käyttö oli pakollista.

Tehtävä 3

a)

Käyttäjät: Työhuonevastaava (T), Amanuenssi (A), Esimies (E) ja Yliopiston henkilöstöhallintajärjestelmä (H)

Käyttötapaukset:

  1. Lisää huone (T)
  2. Poista huone (T)
  3. Muuta huoneen kalustusta (T)
    Esiehto: huone haettu
  4. Hae huoneita (T,A)
  5. Sijoita henkilö huoneeseen (A)
    Esiehdot: henkilön tiedot järjestelmässä, huone haettu
  6. Poista henkilö huoneesta (A)
    Esitehto: henkilö haettu
  7. Siirrä henkilö järjestelmään (A,H)
  8. Generoi raportti (E)

arvosteluperusteet:

  • käyttäjät löydetty 1p
  • jos ulkoinen käyttäjä puuttuu, -1p
  • normaali käyttäjä puuttuu -0.5p
  • jos itse järjestelmä merkitty käyttäjäksi -1p
  • kaavio oikein 1p
  • käyttötapaukset löytyy 1p
    • puutteista -0.25p/puuttuva käyttötapaus
  • käyttötapausten esiehdot ja osallistujat merkitty oikein 1p
    • puuteista -0.25p

b)

  • täysin oikein 1p
  • jokin oleellinen osa (esiehto, jälkiehto, poikkeuksellinen toiminta, käyttäjät, käyttötapauksen kulku) puuttuu -0.25p/puuttuva

c)

Järjesteän ydin oli seuraava:

Tämä oikein tehtynä toi 3p

tämän lisäksi plussaa jos luokkakaaviossa huomioitu:

  • kalustus 0.5p
  • kerros +p
  • raporttien hierarkia 0.5p
  • henkilöstöroolit 0.5p

miinusta jos:

  • jokin järjestelmän ytimen luokista puuttuu 1.5-2p
  • ei sijoitettu henkilöä työpisteeseen 1p
  • toiminnallisuutta kaaviossa 1p
  • asiattomia luokkia 0.5-1p
  • vääriä yhteyksiä 0.5-1p
  • osallistumisrajoite puuttuu 0.5p

neutraalisti suhtauduttiin mm. seuraaviin luokkiin:

  • järjestelmä
  • laitos
  • hakukriteeri

seuraavassa eräs mahdollinen 4 pisteen ratkaisu:

⚠️ **GitHub.com Fallback** ⚠️