Demo 3 - 14.4.
Mallivastaus - Opiskelijoiden vastauksia
3. demoissa keskitytään kohdealuemallinnukseen ja dynaamiseen
mallinnukseen käyttötapauksista yhteistoimintakaavioihin (luennot
6-7).
Demojen tulee olla palautettuna verkossa viimeistään 19.4. klo
12.00. Demot palautetaan NettiDemoWWW:llä. Muista merkitä NettiDemoWWW:ssä
pistemäärä (ja tarvittaessa omia kommentteja). Pisteet voi jakaa
useammalle tiedostolle tai useita tehtäväkohtia voi yhdistää samaan
tiedostoon (suositeltavat
formaatit: teksti, html, kuvaformaatit, pdf).
1. Käsitteitä
Vastaa lyhyesti. Ei esseevastauksia!
1a). Mitä eroa UML-luokkakaaviossa on koosteella
(aggregation) ja kompositiolla (composition)? (2p)
1b). Miten vaatimukset ja käyttötapaukset liittyvät toisiinsa? (1p)
2. Poliisirekisteri
Jatketaan viime demoissa käsitellyn poliisirekisterin
määritystä. Voit käyttää yhteistoimintakaaviossa joko visuaalisia
stereotyyppejä (vrt. kirjastojärjestelmän
Lainaus-toiminto) tai tavallisia luokkasymboleja (vrt.
Palautus-toiminto).
2a). Muodosta Kirjaa rikos järjestelmään-käyttötapauksen pohjalta korkean tason yhteistoimintakaavio (robustness diagram tai collaboration diagram, jossa mahdolliset kutsuttavien metodien nimet - numerointi ei ole välttämätöntä, mutta hyödyllistä), joka kuvaa Kirjaa rikos järjestelmään-käyttötapauksen kulkua ja huomioi järjestelmän sisäisen rakenteen. (2p)
2b). Muodosta
poliisirekisterin toimintakuvauksen
ja a-kohdan yhteistoimintakaavion pohjalta poliisirekisterin
kohdealuemalli. Esitä malli analyysivaiheen luokkakaaviona.
(2p)
Lisätietoa luokka- ja yhteistoimintakaavioista:
- Harjoitustyön 2. vaiheen kuvaus,
- Agate-casen analyysikuvaukset (collaboration diagram)
- ICONIX: Robustness Analysis, Agile modeling: Robustness Diagrams, ddj: Successful Robustness Analysis (robustness diagram)
StarUML-vinkkejä yhteistoimintakaavioiden piirtoon
wikissä. Ks. myös muiden ohjelmien ohjeita.
3. Rahaliikenteen seurantajärjestelmä
Käy läpi seuraava toimintakuvaus:
Yleistä
Tulojen ja
menojen kirjaaminen on hyvä tapa selvittää, mistä menoista ja
kuinka paljon voi tinkiä vaikkapa lomautetuksi joutuessaan. Monelta
tämä kuitenkin jää tekemättä tai vähintäänkin seuranta repsahtaa
hetikohta lupaavan alun jälkeen. Kirjauksia pitäisi tehdä
säännöllisesti, mutta joinakin päivinä ei vain ehdi tai
jaksa.
Tavoite on määritellä järjestelmä, joka helppokäyttöisyydellään
auttaisi tätä tehtävää. Järjestelmä pystyy osoittamaan kohteen
(kuten kauppaliikkeen, huvipaikan tai vaikkapa kirjakerhon) jonne
rahat ovat hävinneet. Tästä kohteesta riippuen saatetaan jatkossa
tarvita siihen kohdistuvaa tarkempaa seurantaa, mutta ko. toiminta
on (ainakin aluksi) rajattu tämän järjestelmän
ulkopuolelle.
Järjestelmän rakenne ja
toiminta
Järjestelmään voidaan ottaa käyttöön useita rahaläheitä (pankkitilit, lompakko, auton tuhkakuppi jne), joiden välillä voidaan tehdä rahansiirtoja (esim. käteisen nosto tililtä, tilisiirrot). Kukin meno (esim. maksettava lasku) voidaan maksaa miltä tahansa rahalähteestä. Tositteen kirjaukseen liitetään tieto rahalähteestä (pankkikortti, käteinen, lasku,...).
Järjestelmää käyttöönotettaessa rahalähteisiin syötetään alkusaldot. Saldoja tulee kuitenkin pystyä muuttamaan myöhemmin.
Kirjausta tehdessä oletetaan tapahtumapäiväksi menossa oleva päivä. Päivää tulee kuitenkin olla helppo muuttaa (kirjauksia jää kuitenkin rästiin).
Usein toistuvien vakiotapahtumien (lounas työpaikalla, kuukausipalkka) tulee olla (hintoineen) valittavissa nopeasti. Hintaa tulee kuitenkin pystyä muuttamaan (perjantaina pihvilounas).
Aina haluttaessa (esim. tiliotteen saapuessa) järjestelmä täsmäytetään: Siihen syötetään tiliotteen loppusaldo ja päivämäärä, jolloin järjestelmä ilmoittaa onko ko. tiliin kohdistuvien kirjausten perusteella tullut sama saldo kuin tiliotteella. Jos saldot poikkeavat, tulee järjestelmän sallia tapahtumien läpikäynti yksi kerrallaan ja virheiden korjaus. Jos virheitä ei löydy, tulee voida lisätä saldoero-tapahtuma (jotta seuraava jakso saadaan kohdalleen). Täsmäytyksen jakso voidaan syöttää järjestelmään. Sitä tulee pystyä muuttamaan.
Järjestelmän tulee pystyä tuottamaan raportteja kuukausittain, viikoittain ja kohteittain.
Eri kohteista voidaan muodostaa ryhmiä (esim. eri ruokakauppojen ostokset), ja raportteja voidaan saada sekä ryhmien väliltä ja ryhmien sisäisesti (onko ruokaan mennyt enemmän kuin bensaan, mihin ruokakauppaan on mennyt eniten).
Järjestelmään voidaan määritellä hälytysraja, joka vilkuttaa violettia kun jakson kyseisen ryhmän kulut ovat 90 % sallitusta ja punaista, kun sallittu raja ylittyy.
3a). Muodosta toimintakuvauksen pohjalta rahaliikenteen seurantajärjestelmän kohdealuemalli. Esitä malli analyysivaiheen luokkakaaviona. (4p)
3b). Pohdi, millaisissa
tilanteissa kohdealuemalli kannattaa luoda yksittäisten
käyttötapausten ja yhteistoimintakaavioiden pohjalta ja milloin
suora toimintakuvauksen käsittely riittää? Onko valinnalla
vaikutusta kehitysprosessin myöhempiin vaiheisiin? (2p)
