ISD-menetelmät

ISD-menetelmät voidaan karkeasti ottaen jakaa rakenteisen suunnittelun (struc-tured desing/analysis) menetelmiin ja oliosuuntautuneisiin (object-oriented) menetelmiin.

Rakenteinen suunnittelu

Rakenteisella suunnittelulla tarkoitetaan vaiheittain kokonaisuuksista yksityis-kohtiin menevää suunnitteluperiaatetta. Ensin kuvataan kokonaisuus, joka suun-nittelun edetessä jaetaan yhä pienempiin osiin. Hierarkkinen ositus muodostaa loogisen kokonaisuuden. Osittaminen tapahtuu sellaisilla kuvaustavoilla, jotka tukevat sekä suunnittelun että ohjelmointityön jakamista itsenäisesti hallittaviin osiin. Suunnittelun keskeisenä kuvauskohteena ovat tietovirrat. Muita keskeisiä käsitteitä ovat prosessi/toiminto, tietovarasto ja ulkoinen kohde.

Rakenteisen suunnittelun menetelmät perustuvat selkeästi määriteltyyn, vaiheit-taisen etenemistapaan. Ne tuottavat melko helposti ymmärrettäviä malleja koh-dejärjestelmän toiminnasta. Sopivalla tavalla soveltaen niitä voidaan hyödyntää myös koko organisaation toimintojen kuvaamiseen, vaikka ne on yleensä tar-koitettu rajatumpien kohteiden kuvaamiseen.

Yksi laajalle levinneistä rakenteisen suunnittelun menetelmistä on SADT ja sen johdannainen IDEF0 (FIPS 1993). IDEF0-kuvaustavan perusrakenne on esitetty kuvassa 3 ja kuvauskohteen osittamisen periaate on esitetty kuvassa 4.

TOIMINNON NIMI Ohjaus

Syöte

Mekanismi

Tulos

Kuva 3. IDEF0-kuvaustavan peruselementit.

4 3

2 1

3 2

1 A0

A4 A-0

Yleisempi kaavio

Yksityiskohtaisempi

Laatikon sisältö tarkemmin tässä toisessa kaaviossa

A4

Numerot osoittavat A42 kuvauksen tasoa.

A0 0

Kuva 4. IDEF0-rakenteinen kuvaustapa.

Rakenteisen suunnittelun menetelmät ovat perinteisesti painottaneet suunnitte-lussa tietoa ja prosessia, ts. miten tieto kulkee prosesseissa ja miten sitä käsitel-lään eri vaiheissa. IDEF0:n kaltainen menetelmä ottaa myös jossain määrin kantaa toiminnan ohjausrakenteisiin ja toimijoihin. Näin ollen sen voidaan katsoa tarvittaessa mahdollistavan myös roolien kuvaamisen. Rakenteisen me-netelmän tuottamat kuvaukset ovat yleensä semanttisesti selkeitä: virhetulkintoja tulee harvoin, jos kuvaussymbolit on selkeästi määritelty. Mikäli tämä etu halu-taan säilyttää, on rakenteista kuvaustapaa uusiin tarkoituksiin (esim. tavoitteiden kuvaamiseen) sovellettaessa pidettävä mielessä notaation yksityiskohtainen määrittely. Esimerkiksi vaatimusmäärittelyyn rakenteisen suunnittelun menetel-mät soveltuvat varsin hyvin, kun kuvauksia tehtäessä muistetaan, että kyseessä on nimenomaan järjestelmän toiminnallisten vaatimusten kuvaaminen eikä toteutuksen suunnittelu (vaatimusmäärittelyvaiheessa voidaan unohtaa monia käyttäjän kannalta vähän kiinnostavia toteutuksen yksityiskohtia).

Oliosuuntautunut suunnittelu

Oliosuuntautunut suunnittelu tarkoittaa sitä, että ohjelmistoa tai järjestelmää suunniteltaessa pyritään etsimään ja mallintamaan kohdealueen luonnollisia kokonaisuuksia, joita kutsutaan olioiksi. Suunnittelussa pyritään mahdollisim-man suureen vastaavuuteen reaalimaailmahdollisim-man ja siitä laadittavan mallin välillä.

Oliosuunnittelussa pyritään siis esittämään kohteet sellaisina kuin ne todellisuu-dessa ilmenevät toiminnallisine ja muine ominaisuuksineen.

Olioajatteluun liittyy keskeisesti hierarkkinen jäsennystapa ja yksityiskohtien piilottaminen. Hierarkkinen jäsennys tarkoittaa olioluokkien järjestämistä hie-rarkkisesti siten, että alemman luokan oliot perivät ylemmän luokan ominaisuu-det (kuva 5). Periytyminen onkin olioajattelun ehkä keskeisin piirre. Yksityis-kohtien piilottamisella tarkoitetaan sitä, että olioluokan toteutuksessa ei tarvitse ottaa huomioon muiden olioluokkien toteutusta. Oliot tietävät toisistaan vain sen, mitä palveluja ne voivat toisiltaan saada, mutta eivät sitä, miten palvelu on tuotettu. Tällainen yksityiskohtien piilottaminen helpottaa oleellisesti olioiden käyttämistä itsenäisinä komponentteina eri sovelluksissa. Oliosuunnittelua onkin pidetty tärkeänä askeleena kohti tietojärjestelmäkomponenttien uudelleenkäyt-töä. Olioajattelun peruspiirteet tukevatkin tätä tavoitetta. Siitä huolimatta oliolä-hestymistapa ei ole ainoa ratkaisu tietojärjestelmien uudelleenkäytön alueella.

Päivittää

Kuva 5. Esimerkki oliokaaviosta.

Oliomenetelmät ovat jossain määrin toteutusorientoineempia kuin rakenteisen suunnittelun menetelmät. Tällä tarkoitetaan lähinnä sitä, että oliosuunnittelu etenee ”liukuvasti” kohti toteutusta (luokkien suunnittelu → luokkien toteutus), kun taas rakenteisen suunnittelun ja toteutuksen raja on selvemmin määriteltä-vissä (suunnitelmien ”kääntäminen” ohjelmointikielelle). Oliomenetelmien painopiste on tiedon ja tehtävien (reaalimaailman kohteiden ja niihin liittyvien tehtävien) mallintamisessa. Oliomallintamisessa voidaan kuvata myös tehtävä-ketjuja (esim. käyttötapaukset) tai prosesseja (esim. toimintakaavio). Olioajat-telun keskeinen periaate kulminoituu kuitenkin olioluokkiin liittyvien tietojen ja toiminnallisuuden kuvaamiseen. Olioluokkien suunnittelu ja toteutus, jotka tukevat kyllä hyvin komponenttiajattelua, eivät välttämättä tue esim. liiketoi-mintaprosesseihin perustuvaa ajattelutapaa.

Menetelmäriippumattomat kuvaustavat

On teoreettinen ongelma vetää tarkkaa rajaa menetelmien ja kuvaustapo-jen/tekniikoiden välille. Menetelmäkuvauksen katsotaan yleensä sisältävän paljon tietoa mallintamisprosessista, mutta niin myös kuvaustekniikankin tulee

sisältää jonkinlaiset ohjeet siitä, miten kuvaus koostetaan. Niinpä periaatteessa irrallisia kuvaustapoja voidaankin käyttää ”menetelmämäisesti” ottamalla huo-mioon mallinnuksen tarkoitus ja konteksti. Hyvin usein kokonaisvaltaisten me-netelmien sijaan käytetäänkin yksittäiseen tehtävään soveltuvaa menetelmäriip-pumatonta kuvaustapaa. Esimerkiksi oliosuunnittelussa tämä suuntaus on johta-nut UML-kuvauskielen kehittämiseen (ks. Fowler ja Scott 1997). Seuraavaksi tarkastelemme esimerkinomaisesti, millaisia yleiskäyttöisiä kuvaustapoja on tarjolla.

Työnkulkukaaviot (Process flowcharts)

Lähes koko atk-pohjaisten tietojärjestelmien historian ajan on järjestelmien toimintaa kuvattu työnkulkukaavioiden avulla. Tavoitteena on ollut toistuvien tehtäväkokonaisuuksien hahmottaminen ja usein prosessien pitkälle viety auto-matisointi. Työnkulkujen suunnittelussa käytetään yleensä jonkinlaista graafista työkalua, jolla voidaan määritellä työnkulkuun kuuluvat osatehtävät, niiden suoritusriippuvuudet ja mahdolliset toimintoihin liittyvät vaatimukset.

Työnkulkua kuvaavat graafiset mallit eli työnkulkukaaviot voidaan jakaa 1) viestintäpohjaisiin, 2) toimintopohjaisiin sekä 3) hybridimalleihin (Joutsjärvi 1996). Viestintäpohjaisia malleja ovat neuvottelu- ja puheaktimallit. Neuvotte-lumalli kuvaa liiketoimintaprosessin yksittäiset toiminnot nelivaiheisina silmu-koina, joilla pyritään kuvaamaan viestintää suorittajan ja asiakkaan välillä.

SAMPO (Speed act-based information analysis methodology with computer-aided tools) on puheaktiteoriaan perustuva, neuvottelumallia kattavampi ku-vausmenetelmä, joka auttaa havainnoimaan ristiriitaisuuksia ja epätäsmällisyyk-siä viestinnässä ja sitoutumisessa tehtävien suorittamiseen (Auramäki et al.

1992). Puheakti on SAMPO-menetelmässä yksittäinen viestintätapahtuma ja keskustelu on järjestetty puheaktien sarja. Toimintopohjaiset mallit ovat vuokaa-vioita, jotka kuvaavat työn suoritusjärjestystä, mutta eivät ota huomioon suorit-tajia. Hybridimalleissa esitetään useampia työnkulun ulottuvuuksia yhtä aikaa, kuten tehtävien suorittajat ja tehtävien suoritusjärjestys.

Käsitemallit (Entity-relationship models)

Siinä missä työnkulkukaaviot kuvaavat järjestelmää peräkkäisten toimenpiteiden muodostaman dynamiikan näkökulmasta, on järjestelmän staattisen rakenteen

kuvaamiseen luotu myös joukko kuvaustapoja. Tietojärjestelmien kehittämisen alueella käytetyimpiä lienevät erilaiset käsitemallinnustekniikat. Niiden avulla pyritään löytämään reaalimaailman kohteita, joihin liittyvään tietoon mallinnet-tavan järjestelmän toiminta kohdistuu. Järjestelmän kohdealueesta muodostetaan käsitemalli, joka kuvaa paitsi relevantit kohteet, myös niiden väliset suhteet (kuva 6). Käsitemallia voidaan täsmentää liittämällä siihen kohteita kuvaavia attribuutteja. Englannin kielessä laajennetusta käsitemallista puhutaan nimellä

’ERA model’ (Entity-relationship-attribute model). Kohteiden välisiä suhteita voidaan niin ikään kuvata eri tarkkuustasoilla (esim. asettaa tai olla asettamatta suhteisiin rajoitteita tai ehtoja).

Osa#

Kuva 6. Esimerkki käsitemallista (Entity-Attribute-Relationship model).

Käsitemallit ovat käyttökelpoisia sekä rakenteisessa että oliosuunnittelussa, mutta varsinkin oliosuunnittelussa ne palvelevat hyvin olioluokkien määrittelyä.

Oliomenetelmien olioluokkakaaviot muistuttavatkin hyvin pitkälle käsitemalleja sillä erotuksella, että olioluokkakaavioissa otetaan yleensä huomioon huomatta-vasti enemmän toteutuksessa tarvittavia näkökohtia ja sen vuoksi niissä on

mää-ritelty myös olioiden toiminnalliset piirteet. Viitekehyksessämme käsitemallit sijoittuvat puhtaasti tiedon mallintamiseen.

UML:n sisältämiä kuvaustapoja

UML (Unified Modeling Language) sisältää suuren joukon erilaisia kuvausta-poja, jotka on koostettu useista eri oliopohjaisista menetelmistä (OMG 1999, Fowler ja Scott 1997). Seuraavassa käydään lyhyesti läpi keskeisimpien UML:n kuvaustapojen (tekniikoiden) käyttötarkoitukset.

− Toiminta- ja aktiviteettikaavio (activity diagram) kuvaa käyttäytymistä ja kontrollirakenteita. Se soveltuu varsinkin tilanteisiin, joissa on useita rin-nakkaisia prosesseja (prosessi haarautuu). Riippuen siitä, onko kyseessä kä-sitetason vai toteutustason mallinnus, toiminnalla (activity) tarkoitetaan joko suoritettavaa tehtävää tai olioluokan metodia (toiminnallista ominaisuutta).

− Luokkakaavio (class diagram) kuvaa kohdealueen käsitteiden, tyyppien ja luokkien staattisen rakenteen. Käsitteet ovat tapa kuvata käyttäjän näkökul-masta kohdealuetta. Tyypit puolestaan kuvaavat ohjelmistokomponenttien väliset rajapinnat. Luokat kuvaavat ohjelmistokomponenttien toteutuksen.

− Toteutus- ja sijoittelukaavio (deployment diagram) on varsin vähän käytetty kuvaustapa, jonka avulla kuvataan ohjelmisto- ja laitteistokomponenttien liittyminen toisiinsa.

− Pakkauskaavio (package diagram) kuvaa luokkien ryhmät ja niiden keski-näiset riippuvuudet.

− Käyttötapaus (use case) esittää käyttäjien vaatimukset tarkoituksenmukaisina kokonaisuuksina tai siivuina. Rakennesuunnittelu tehdään joidenkin käyttöta-pausten ympärille. Käyttötapaus toimii perustana järjestelmän testaamiselle.

− Vuorovaikutuskaavio (interaction diagram) kuvaa sitä, kuinka useat oliot kommunikoivat yksittäisessä käyttötapauksessa.

− Tilakaavio (state diagram) kuvaa yksittäisen olion käyttäytymistä useassa käyttötapauksessa.

UML:n kuvaustapakokoelma on laaja. Kärjistäen voidaan kuitenkin sanoa, että UML:n kuvaustavat kokonaisuudessaan painottavat hyvin pitkälle samoja näkö-kulmia kuin kattavat oliosuuntautuneet menetelmätkin.