Demo 3 - 16.4.
Mallivastaus - Opiskelijoiden vastauksia
3. demoissa keskitytään kohdealuemallinnukseen ja dynaamiseen
mallinnukseen käyttötapauksista yhteistoimintakaavioihin (luennot
7-8).
Demojen tulee olla palautettuna verkossa viimeistään 22.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)? (1p)
1b). Miten vaatimukset ja käyttötapaukset liittyvät toisiinsa? (1p)
1c) [Lähde:
Bennett, teht. 8C]. Käy läpi Agate-casen yleiskuvaus
ja sen perusteella muodostettu mainoksiin liittyvä alustava
luokkakaavio (s. 236-238,
luku 8.3.3 ja kuva 8.8). Piirrä luokkakaavio uudelleen
täydennettynä kuvauksen perusteella eri mainostyypeillä.
Mahdollisia uusia luokkia voisivat olla ainakin MagazineAdvert, PosterAdvert ja
LeafletAdvert. Tarvitaanko
muita (yli)luokkia, joissa yksittäisten mainostyyppien yhteisiä
ominaisuuksia tai toimintoja on pakattu yhteen (esim. PrintMediaAdvert)? (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)
- Agile modeling: Robustness Diagrams, Successful Robustness Analysis (robustness diagram)
StarUML-vinkkejä yhteistoimintakaavioiden piirtoon:
- Robustness diagram-symbolit löytyvät
luokkakaaviosta (analysis-työkalut), Collaboration diagram on oma
kaavionsa.
- Vaihtoehtoisesti myös tavallisen yhteistoimintakaavion käyttö on mahdollista. tällöin <<boundary>>, <<control>> ja <<entity>> -stereotyypit merkattava olioihin
- Aktorisymbolia ei ole yhteistoimintakaavion työkalupaletissa, mutta aktorin voi "vetää" käyttötapauskaavion mallista model explorerista.
- Model explorerista voi "vetää" jo mallinnettuja luokkia kaaviosta toiseen
- Robustness diagram -kaaviossa olevien viivojen
määrä kasvaa helposti. viestejä voi tarvittaessa "pakata yhteen"
esim. merkitsemällä lähtö- ja paluuviestin saman viivan eri
reunoihin.
- Uml-yhteistoimintakaaviossa nuolet saa näkyviin merkitsemällä aluksi olioiden välille linkin, jonka jälkeen linkkiviivaa on klikattava stimulus- tai response-työkalulla.
- Jos robustness-kaavioon vedetään luokkakaavioon
jo merkitty luokka, ohjelma näyttää luokan tavanomaisena
suorakulmiona. ulkoasun saa muutettua visuaaliseksi stereotyypiksi
valitsemalla kaavioelementin popup-valikosta format-> stereotype
display->iconic ja tarvittaessa format->suppress
attributes/operations
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)
