Mallinnus ja menetelmät -seminaari 2.-4.9.2003
Systemityö-yhdistys Sytyke, Silja Serenade
* Mallinnus RUP:ssa
* Mallinnus keinona ohjelmistotyön tuottavuuden nostamiseen
* Informaation mallintaminen
* Mitä uutta UML 2.0 tuo tullessaan?
* Perinteinen oliomenetelmä ketteräksi
* MDA
* Määrittelymallit
* Systeemityön vallankumous – toimitusjohtaja puuttuu asiaan!
Mallinnus RUP:ssa, Jouko Poutanen, Rational Software
UML:llä voidaan nykyään mallintaa monia asioita, myös arkkitehtuuria. RUP eli Rational Unified Process on kuin buffet-pöytä, jossa ruokalajeina on koeteltujen reseptien mukaan valmistettuja systeemityön parhaita käytäntöjä.
Muutokset ovat todellisuutta, jota ei voi välttää. RUP jatkuvine laadunvarmistuksineen tarjoaa erään keinon tulla toimeen niiden kanssa, ja sopii erinomaisesti monitoimittajaympäristöön.
Pelkkä mallinnuskieli, UML, ei riitä. Lisäksi pitää sopia, millä tarkkuudella ja milloin mallinnetaan, kuka sen tekee ja ketä varten. Projekteissa on yleensä sen verran tiukkaa, että turhiin harjoituksiin ei ole aikaa.
Nykyinen järjestelmäkehitys on mallikeskeistä. Visuaaliset mallit tehostavat kommunikointia. Mallit eivät ole pelkästään kuvauksia vaan niistä voidaan generoida niin lähdekoodi kuin testauskin.
Mallinnus keinona ohjelmistotyön tuottavuuden nostamiseen, Pekka Kähkipuro, SysOpen
Systeemityöltä vaaditaan tänä päivänä tukea nopealle evoluutiolle. Liiketoiminta muuttuu nopeasti, samoin tekniikka mahdollisuuksineen. Kymmenessä vuodessa on tapahtunut muutos: järjestelmäkehitys on tänä päivänä liiketoimintavetoista ja tukee heterogeenisuutta. Tuottavuusvaatimukset ovat ennennäkemättömät. Projektit, jotka aiemmin kestivät pari vuotta, pitää nykyisin viedä lävitse kuudessa kuukaudessa. Nämä ovat haasteita, joihin ei ole olemassa malleja historiassa!
Aikatauluvaatimukset ovat menneet sellaisiksi, että koodauksen pitäisi alkaa heti – ja niinhän se alkaakin. Kevytmallinnus tai mallinnuksen jättäminen kokonaan pois on yhä tavallisempaa. Yksinkertaisissa sovelluksissa tämä voi toimia, mutta mitä monimutkaisemmasta järjestelmästä on kysymys, sitä vaikeammaksi tai lopulta mahdottomaksi sen tekeminen ilman mallintamista muodostuu.
Projektin pilkkominen riittävän pieniin osiin tai puolivalmisteiden käyttö ovat eräitä vastauksia nykyisiin tuottavuus- ja aikatauluvaatimuksiin, mutta uudenlaisia lähestymistapoja tarvitaan. Tuottavuus on pysyvä haaste! Määrämuotoinen työskentely on rapautumassa. Jos organisaation oma IT-osasto ei kykene lunastamaan lupauksia, organisaatio oman järjestelmäkehityksen sijaan päätyy helposti valmistuotteiden hankintaan.
Informaation mallintaminen, Esko Marjomaa, Joensuun yliopisto
Analyyttisen filosofin ottein ilman kalvoja, jotka olivat unohtuneet Joensuuhun, Esko Marjomaa esitteli meille informaation, tiedon ja mallinnuksen sanakirjamääritelmiä – ja sitten osoitti, kuinka paljon yksinkertaisempaa on käsitteiden tarkastelu niiden perusideoista lähtien.
Hän esitteli meille mm. omia periaatteitaan, joihin ei ole törmännyt muualla kuin omissa kirjoituksissaan. Formalisointiperiaate sanoo: ”Ollakseen implementoitava käsitekaavion on oltava formalisoitavissa.” Semioottinen periaate sanoo: ”Käsitekaavion pitäisi olla helposti tulkittavissa ja ymmärrettävissä.” Keskustelussa ilmeni, että Esko Marjomaa ei tarkoita käsitekaaviolla esim. UML-notaatiolla piirrettyä liiketoimintamallia vaan pikemminkin miellekarttaa, Mind Mapia.
Lopuksi hän kertoi meille tarinan: ”Oletetaan pyöreä lehmä…”
Hän neuvoi: ”Jos se toimii, hyödynnä sitä. Jos se toimii edelleen, kopioi se.”
Mitä uutta UML 2.0 tuo tullessaan? Tarja Raussi, Tieturin systeemityöosasto
UML 2.0 tuo tullessaan kolme uutta kaaviota, joista yksi on koosterakennekaavio luokan tai komponentin sisäisen rakenteen kuvaamiseen, toinen ajoituskaavio ja kolmas profiilikaavio. Mustapäinen nuoli tarkoittaa laajennusta (Extension) ja pavut (Beans) ovat komponentteja. Käyttötapauskaavioon saa tikku-ukon tilalle piirtää laitteen kuvaamaan, että toimijana on toinen sovellus.
Sekvenssikaaviossa voidaan kuvata vuorovaikutuksen jakaminen osiin. Yhteistyökaavio (Collaboration Diagram) katoaa ja sen tilalle tulee kommunikaatiokaavio (Communication Diagram). Muutos on sikäli ymmärrettävä, että yhteistyökaaviota on tähän asti käytetty pääasiassa kuvaamaan kommunikaatiota.
Toimintokaaviolla voidaan kuvata prosesseja ja niiden aliprosesseja. Toiminnallisuuden jakoa (Activity Partition) kuvataan uimaradoilla (Swimlane), jotka voivat olla hierarkkisia. Solmun sisään voidaan piirtää toinen solmu.
Perinteinen oliomenetelmä ketteräksi, Heini Holopainen ja Eija Hamina-Mäki, Tietoenator
Yksinkertaisuuden, joustavuuden ja vuorovaikutuksen avulla keskitytään hallitsemaan epätäydellisyyttä. Heini Holopainen luetteli monia ketteriä (Agile) menetelmiä. Esim. XP, jonka Beck kuvasi vuonna 1999, on kurinalainen menetelmä: projektiryhmä työskentelee vain virka-aikana, kaikki keskenään samassa tilassa, jonka kalustearkkitehtuuri on määritelty menetelmässä. DSDM-menetelmässä taas pidetään kiinni annetusta ajasta ja resursseista ja tehdään se, mitä niiden rajoissa ehditään ja pystytään.
Perinteisissä oliomenetelmissä vaiheet ovat näkyvissä ja kunkin vaiheen lopputuloksena syntyy tietynlainen kuvaus. Eija Hamina-Mäki esitteli TE Object -menetelmän, joka koostuu peräkkäisistä tai rinnakkaisista sovelluskehistä. Joka kierroksella kehä tuottaa käyttöönotettavia toteutuseriä. (TE Objectista mieleeni tuli vuoden 1993 Sytyke-raportissa STST-malli kuvattu palasteleva, spiraalimainen sovelluskehitysmalli, joka tosin ei ollut oliopohjainen.)
Ketterät menetelmät asettavat erityisiä haasteita projektinhallinnalle, kun suuri kokonaisuus on pilkottu pieniin osiin, jotka pitäisi koordinoida. On tärkeätä muistaa, että ketteryys liiketoimintajärjestelmien kehittämisessä ei tarkoita tehokkuuden lisäämistä ja kustannusten minimointia niin, että se tehtäisiin järjestelmän laadun kustannuksella!
Seminaarin osallistujille jätettiin kotitehtäväksi pohtia, mitä haasteita ketterä lähestymistapa tuo käytännön ohjelmistotuotantoon.
MDA, Henrik Jondell, Borland
Monimutkaisuus kasvaa jatkuvasti, muutosvauhti kiihtyy, tietojärjestelmiä ei rakenneta pysyviksi, ennustaminen on tuskallista ja ylläpidon kustannukset kasvavat loputtomiin. Tämä on todellisuutta tämän päivän yrityselämässä ja järjestelmäkehityksessä.
MDA eli Model Driven Architecture tekee sovelluskehityksen alustariippumattomaksi (Platform Independent Model). Sen avulla muutokset voidaan ottaa käyttöön nykyistä helpommin ilman sivuvaikutuksia.
Malli on koodi: mallista voidaan generoida koodi ja päinvastoin. MDA rakentuu UML:n varaan, johon tehdään tarvittavat lisäykset.
Henrik Jondell demosi, miten MDA toimii käytännössä. Hän piirsi yksinkertaisen luokkamallin attribuutteineen ja yhteyksineen, painoi nappia ja sai aikaan koodin, jossa tästä liiketoimintamallista oli automaattisesti johdettu suunnittelutason malli Borlandin omalle alustalle. Hän myönsi, että mallin generointi ei välttämättä toimi jokaisessa laiteympäristössä, mutta ilmeisesti useammassa kuin yhdessä.
Hän näytti myös, miten muutokset toteutetaan. Hän lisäsi liiketoimintatason luokkamalliin attribuutin, jolloin hän sai päivitetyn version suunnittelutason mallista sekä listauksen muutoksista, jotka siihen automaattisesti oli tehty.
Määrittelymallit, Markku Niemi, STTF
Markku Niemi esitteli viime vuonna ilmestyneen TTL:n julkaisun Tietojärjestelmän hankinta ja IT2000-sopimusehdot. Julkaisun tekemiseen osallistuneen työryhmän jäsenistä valtaosa oli mukana seminaarissa. Julkaisussa oli tingitty UML:n käsitteiden suomennoksista ja käytetty ymmärrettävyyden vuoksi luokkamallin sijasta termiä käsitemalli ja käyttötapauksen sijasta termiä käyttötilanne. Käsitteistä syntyi seminaarissa kohtalaisen kiihkeä keskustelu, jota osin edesauttoi se, että systeemityön ammattilaisten oma kokemus luokkamallin ja käsitemallin käytöstä ja käyttötilanteista on vaihteleva.
Systeemityön vallankumous – toimitusjohtaja puuttuu asiaan! Claus Günther, ChangeWare Group
Systeemityön vallankumouksen ensimmäisessä aallossa tulivat lähiverkon myötä talon sisäisten prosessien hallinta. Toista aaltoa vauhditti Internet, joka on tuonut systeemityöhön organisaatioiden väliset prosessit.
Prosessista siirrytään työvirtojen (Workflow) kautta liiketoimintaprosessien hallintaan (BPM, Business Process Management). Prosesseista puolestaan siirrytään valmisohjelmistoihin kuten SAPiin (SAP tosin ei perustu UML-kaavioihin, koska se on kehitetty ennen niitä). Haasteena on paradigmamuutos ERP-aikakaudesta verkkoliiketoimintaan (e-business) ja yritysportaaleihin.
Käsitteistä Efficiency ja Effectivity Claus Günther sanoi: ” Tee työsi oikein… tee oikea työ”. Ketteryydestä, josta aiemmin puhuttiin (vrt. Heini Holopainen ja Eija Hamina-Mäki: Perinteinen oliomenetelmä ketteräksi), on nyt siirrytty elastisuuden käsitteeseen.
MDA:sta (vrt. Henrik Jondell: MDA) pitäisi siirtyä käsitteeseen BDIT eli Business Driven IT. Jokainen IT-hanke tarkoittaa muutosta – ja kehittämistä ja kouluttamista.
Lopuksi muutama haiku
Risteilyn teema:
mallinnus, menetelmät.
Nostetaan malja!
Todellisuuden
rakennamme malliksi,
saamme systeemin.
Mahtava anti!
Sytyke systeemityön
soihdun sytyttää.
Sivu päivitetty 23.08.2004
Eija Kalliala
Vastaa