Suunnittelu

Oliomallinnuksen haasteita

Alla on lueteltu oliomallinnuksessa kohdattavia tyypillisiä ongelmatilanteita

Luokat ovat ongelmallisia, kun ne ovat:

1. Redundantteja eli pällekkäisiä: eri luokat sisältävät samoja ominaisuuksia, mutta eri nimisinä. Esimerkiksi Asiakas ja Käyttäjä
2. Epärelevantteja: luokat eivät ole ongelman, eivätkä sen ratkaisun kannalta olennaisia.
3. Epämääräisiä: luokat ovat rajaukseltaan tai sisällöltään täsmentymättömiää.
4. Pikemminkin attribuutteja: luokat kuvaavat johonkin muuhun luokkaan kuuluvia ominaisuuksia, eivät ole itsenäisiä kokonaisuuksia.
5. pikemminkin operaatioita: luokat kuvaavat johonkin luokkaan kuuluvien olioiden käyttäytymistä.
6. Pikemminkin rooleja: luokan nimi viittaa enemmän olion asemaan suhteessa toiseen olioon, kuin sen perimmäiseen luonteeseen.

Assosiaatioiden tyypillisiä ongelmia ovat:

1. Epärelevantit assosiaatiot: olioilla väitetään olevan yhteyksiä, vaikkei niin todellisuudessa ole.
2. Pikemminkin operaatio: assosiaation tulee kuvata rakenteellista piirrettä, ei sanomaa eikä operaatiota.
3. Monimutkaiset assosiaatiot: useampaa kuin kahta olioluokkaa koskevat assosiaatiot voidaan usein pilkkoa ja näin saada rakenteesta ymmärrettävämpi ja helpompi toteuttaa.

Attribuutit ovat ongelmallisia, jos ne ovat:

1. Pikemminkin olioluokkia: jos attribuutista ollaan kiinnostuneita muutenkin kuin karakterisoivana, eli toista olioa kuvaavana ominaisuutena, on se mahdollisesti olioluokka.
2. Pikemminkin oliotunniste: jos attribuutilla ei ole todellista vastinetta (arvoa).
3. Yhteensopimattomia attribuutteja: jos attribuutit poikkeavat merkittävästi luokan muista attribuuteista luonteensa puolesta, voi olla syytä jakaa luokka kahtia.

Tapoja uudelleenorganisoida luokkia:

1. Alhaalta-ylös: etsitään samanlaisia attribuutteja ja assosiaatioita sisältäviä luokkia ja selvitetään, ovatko ne osa yleistyshierarkiaa?
2. Ylhäältä alas: tarkastellaan luokkia, joilla on paljon attribuutteja. Ovatko attribuutit relevantteja kaikille luokan olioille?
3. Etsitään merkkejä puuttuvista luokista: jos assosiaatioiden ja yleistyssuhteiden välillä on epäsymmetrisyyttä: lisää uusia luokkia
4. Jos luokassa on epäyhtenäinen joukko attribuutteja ja operaatioita: jaa luokka osiin
5. Jos luokkaan ei löydyä attribuutteja, assosiaatioita eikä operaatioita, on se merkki puuttuvista tai tarpeettomista assosiaatioista:

Lopuksi yleisiä vinkkejä luokkakaavion toteuttamiseen:

1. Koeta ensin ymmärtää ongelma-aluetta, vasta sitten voit määritellä luokkia.
2. Pyri pitämän luokkakaavio yksinkertaisena.
3. Valitse huolellisesti nimet ja selvennä tarvittaessa määrittelyä tietohakemistossa.
4. Mallinna analyysivaiheessa viitteet ja osoittimet luokasta toiseen assosiaatioina, älä attribuutteina

Viikkotehtävät

• 1. Esimerkki: Luokkakaavio ja Oliokaavio
• 2. Esimerkki: Oliokaavio ja Luokkakaavio
• 3. Esimerkki: Luokkakaavio ja Oliokaavio
• 4. Esimerkki: Oliokaavio ja Luokkakaavio
• 5. Esimerkki: Luokkakaavio ja Oliokaavio

Olion ja alkeistietotyypin ero. Sisältää vastauksen myös kysymyksen "onko olion attribuuteille pakko antaa luonnin yhteydessä jokin arvo.

Vaatimusmäärittely

Kotonyan ja Sommervillen (2002, 4) mukaan vaatimusmäärittely kuvaa palvelut, joita järjestelmän tulisi tarjota, sekä rajoitteet järjestelmän toiminnalle. Vaatimukset kerätään erilaisilla tekniikoilla sidosryhmiltä heidän esittämiensä tarpeiden ja toiveiden täyttämiseksi. Tehtävänä on tunnistaa, koota, ryhmitellä, muokata ja karsia tarpeet sekä asettaa ne tärkeysjärjestykseen esimerkiksi teknisten tai taloudellisten tekijöiden perusteella (Kettunen & Simons 2002). Näin tarpeista muodostuu järjestelmään kohdistuvia vaatimuksia, joilla voi olla erilaisia prioriteettitasoja.

Vaatimukset jaetaan toiminnallisiin ja ei-toiminnallisiin. Toiminnalliset vaatimukset määrittävät, millaisia toiminnallisia ominaisuuksia ohjelmistolla tulisi olla van (Lamsweerden 2009). Toiminnalliset vaatimukset voivat viitata ympäristön olosuhteisiin, missä vaatimuksen esittämä toiminto tapahtuu. Pohl (1994) kuvaa toiminnalliset vaatimukset järjestelmän pakollisiksi tehtäviksi. Ei-toiminnalliset vaatimukset puolestaan määrittävät järjestelmän yleiset ominaisuudet ja piirteet (Kotonya & Sommerville 2002).

Malli (model) on kuvaus järjestelmästä tai sen osasta. Mallin avulla voidaan kuvata, millainen ja miten järjestelmä aiotaan toteuttaa.

Malli esittää kokonaisen näkymän järjestelmästä tietyssä kehittämisen vaiheessa ja tietystä näkökulmasta. Kaavio esittää tietyn yksityiskohdan mallista.

Käyttötapauskaavio- ja kuvaukset

Käyttötapauksia pidetään yleisesti hyvänä ratkaisuna erityisesti käyttäjävaatimusten kartoittamiseen (Haikala & Märijärvi 2000). Käyttötapaus tarkoittaa käyttäjien järjestelmällä suorittamia tapahtumaketjuja.

Käyttötapausten suhteet kuvataan käyttötapauskaaviossa, jossa jokaiseen käyttötapaukseen liittyy yksi tai useampi käyttäjärooli. Käyttötapauskaaviossa käyttäjärooli mallinnetaan tikku-ukkona. Yksittäiset käyttötapaukset mallinnetaan soikioina. Käyttötapausten taustalla oleva suorakulmio kuvaa käsiteltävää järjestelmää, johon käyttötapaukset kuuluvat. Käyttäjien ja käyttötapausten välinen yhteys on merkitty viivalla. Käyttötapausten välillä oleva katkoviivanuolella merkitään tilannetta, jossa käyttötapaus laajentaa toista käyttötapausta.

• Aktori (actor) on eränlainen rooli, jossa käyttäjät (esim. operaattori, tietokannanhoitaja, peruskäyttäjä), laitteet (esim. tulostin) tai toiset järjestelmät (kirjanpitojärjestelmä) toimivat ollessaan yhteydessä järjestelmän.
• Kommunikointisuhde aktorin ja käyttötapäauksen välillä osoittaa järjestelmän kytkennän ympäristön,
• Yleistyssuhde (generalization) käyttötapäausten välillä: esimerkiksi käyttäjän tunnistaminen (validate user) voi tapahtua joko salasanan (Check password) tai silmän verkkokalvon skannaamisen (Retinal scan) avulla; merkitys samantapainen kuin luokkien välisessä yleistyssuhteessa
• Sisältymissuhde (include) käyttötapäausten välillä: tarkoittaa, että toinen käyttötapäaus (supplier) voi sisältyä toiseen käyttötapäaukseen (client) viimeksi mainitun kontrollissa ja pättämässä tilanteessa. Esimerkiksi tilauksen teke- minen edellyttä aina käyttäjän tunnistamisen
• Laajennossuhde (extend) käyttötapäausten välillä tarkoittaa, että toinen käyt- tötapäaus laajentaa toisen toiminta-alaa. Esimerkiksi tilausten tekemisessä noudatetaan normaalia toimintatapaa, paitsi kiireellisten tilausten tekemisen (poikkeustapaus) yhteydessä, jossa sovelletaan normaalin toimintatavan lisäksi erityistoimintoja. Edelleen laskun maksamisessa joudutaan joskus suo- rittamaan lisäksi tilinylitysmaksu (kuva 3.2; Jacobson ym, 1999, s. 146).

Malli esittää kokonaisen näkymän järjestelmästä tietyssä kehittämisen vaiheessa ja tietystä näkökulmasta. Kaavio esittää tietyn yksityiskohdan mallista. Malli esittää kokonaisen näkymän järjestelmästä tietyssä kehittämisen vaiheessa ja tietystä näkökulmasta. Kaavio esittää tietyn yksityiskohdan mallista.

Käyttötapauksen sanallista kuvausta kutsutaan skenaarioksi (Schach 2002). Käyttötapausskenaariolla on aina lähtötilanne ja lopputilanne. Käyttötapaus kuvataan järjestelmän ja käyttäjän välisenä vuorovaikutuksena. Kuvaukseen voidaan merkitä huomautuksia ja poikkeuksia. Poikkeuksella tarkoitetaan tilannetta, jossa käyttötapauksen suorittaminen ei onnistu.

Tehtävä 5 käyttötapaukset: Laadi käyttötapauskaavio viikkotehtävässä mallintamastasi järjestelmästä. Kirjoita kahden käyttötapauksen kuvaukset.

Käyttötapauksia voidaan hahmottaa myös aktiviteettikaavioilla, josta esimerkki alla:

Analyysi

Staattinen mallintaminen on järjestelmän rakenteen kuvaamista ja dynaaminen mallintaminen järjestelmän toimintojen ja vuorovaikutuksen kuvaamista. Staattista mallintamista on käsitelty edellisellä kerralla luokka- ja oliokaavioiden avulla.

Dynaamisen mallintamisen tarkoituksena on märitellä olioiden käyttäytyminen: olioiden keskinäisenä vuorovaikutuksena (sekvenssikaavio, yhteistoimintakaavio) ja yksittäisten olioiden tiloina ja tilanvaihtoina (tilakaaviot). Lähtökohätina toimivat vaatimusmärittelyt, käyttötapäaukset, luokkakaavio sekä yleinen asiantuntemus

Sekvenssikaavio

Kuvaa yhden käyttötapäauksen mukaisen vuorovaikutuksen olioiden välillä (aika kulkee ylhältä alas):

• Vuorovaikutukseen osallistuvat oliot kuvataan nimetyillä suorakulmioilla vasemmalta oikealle siinä järjestyksessä kuin oliot lähettävät toisilleen viestejä.
• Viesti on signaali, joka välitetän lähettävältä oliolta vastaanottavalle oliolle, tai operaatiokutsu, jonka vastaanotettuaan olio käynnistä nimetyn metodin toteuttamisen,
• Voi kantaa mukaan parametriarvoja (esim. nappainPainettu(n), hiiriPainikePai- nettu(painike,sijainti)
• Viestin käynnistämä operaatio voi tuottaa palautearvon, mutta vastaavaa palauteviestiä ei useinkaan kuvata, ellei sitä käytetä myöhemäpien kutsujen parametrina.
• Olion elinaika kuvataan pystysuunnassa olevalla katkoviivalla (lifeline);
• Olion aktiivisen toiminnan aika kuvataan paksunnoksella (palkilla).
• Olion luonti voidaan esittä suuntaamalla viestinuoli (create) suoraan ko. oliota vastaavaan suorakaiteeseen (konstruktori, muodostin).
• Olion tuhoaminen osoitetaan palkin loppupän yli vedetyllä ristillä ja palauteviestillä; olion tuhoaminen voi olla myös täoisen olion lähettämän viestin (destroy) seurauksena (destruktori, hajotin – Javan tapauksessa kuvaa tilannetta, kun olioon ei ole enä viitteitä, jolloin se voidaan poistaa muistinsiivouksen yhteydessä )

Tehtävä 6 Sekvenssikaavio: valitse yksi käyttötapaus ja mallinna olioiden välinen viestintä sekvenssikaaviolla.

Suunnittelu

Miten ohjelmiston tulee tehdä se, mitä analyysivaiheessa määriteltiin. Seuraavassa on listattu suunnitteluun kuuluvia osa-alueita, joita ei tällä kurssilla käsitellä tarkemmin:

• Arkkitehtuurin suunnittelu
• Käyttöliityymän suunnittelu ja lisääminen luokkakaavioon (usein käyttöliittymä esitetään vain yksittäisenä luokkana)
• Tietorakenteet
• Algoritmien suunnittelu eli mietitään, miten olioiden metodit toteutetaan
• Luokkarakenteen muokkaaminen periytymistä hyödyntäen
  • Abstrakti luokka = ei olioita, kokoaa yhteen konkreettien luokkien ominaisuudet,
  • Rajapinta = abstraktia luokkaa, joka ei sisällä attribuutteja tai toteutettuja metodeja kutsutaan rajapinnoiksi. Eli määrittelevät, mitä metodeja konkreetti luokka toteuttaa.
  • Konkreetti luokka
• Attribuuttien näkyvyys:
  • yleinen (+): attribuutti tai operaatio on muiden luokkien (olioiden) käytettävissä
  • yksityinen (-): attribuutti tai operaatio ei ole muiden luokkien (olioiden) käytettävissä
  • suojattu (#): attribuuttia tai operaatiota voivat käyttä vain ko. luokan aliluokkien oliot.

Luokkien väliset yhteydet TODOOO

Luokkien väliset yhteydet

Assosiaatioiden toteutuksen suunnittelu

Oletusarvoisesti assosiaatio mahdollistaa suoran viestinnän molempiin suuntiin. Jos suunnittelun aikana haluamme märittä tarkemmin, onko viestintäyh- teys molempiin suuntiin vai vain toiseen suuntaan, voimme tehdä sen avoimella nuolenpällä (association navigation). Esimerkiksi jos salasanaa etsitän pelkästän Käyttäjä-olion kautta, voidaan navigointisuunta märittä kuvan (Booch ym, 1999, 144) kaltaisesti. Yksisuuntaisilla assosiaatioilla voidaan vähentä luokkien väli- siä riippuvuuksia ja näin yksinkertaistaa esim. muistinhallintaa kielillä, joissa ei ole automaattista muistinsiivousta.

Yhden_suhde_yhteen -assosiaatio tarkoittaa sitä, että luokan A mukainen olio voi olla kytketty linkillä vain yhteen luokan B mukaiseen olioon ja päinvastoin:

• Jos viestinnän on tarkoitus tapahtua vain toiseen suuntaan, märitellän lähettävälle luokalle viitearvoinen attribuutti (carObjectId), joka sisältä vastaanottavan olion viitteen (kuva 5.35). ● kaksisuuntainen viestintä:
• Jos viestinnän on tarkoitus tapahtua molempiin suuntiin, märitellän viiteattribuutti molempiin luokkiin.

Yhden_suhde_moneen -assosiaatio tarkoittaa sitä, että luokan A mukainen olio voi olla kytketty linkeillä useampaan luokan B mukaiseen olioon, mutta B mukainen olio voi olla kytketty vain yhteen luokan A olioon.

• Taulukkoviite
• Säiliöluokka

Monen_suhde_moneen -assosiaatio tarkoittaa sitä, että luokan A mukainen olio voi olla kytketty linkeillä useampaan luokan B mukaiseen olioon ja B mukainen olio voi olla kytketty useampaan luokan A olioon

Tehtävä 7 iterointi: päivitetään kaavioita tapaamisessa opittujen asioiden perusteella.

Suunnittelumallit

Oliosuunnitteluun on olemassa valmiita malleja. Ne kuvaavat jonkin tavan yleisesti esiintyvän ongelman ratkaisemiseksi. Mallit eivät ole ohjelmakoodia, vaan dokumentti, jossa kuvataan mallin rakenne, ratkaisema ongelma, edut, haitat sekä vaihtoehtoiset mallit. Suunnittelumallien taso vaihtelee. Osa kuvaa ratkaisuja hyvin yksityiskohtaisesti, toiset arkkitehtuuritason ongelmien ratkaisemiseen.

• ← Analyysi
• Java perusteet →