DO NOT PRINT THIS DOCUMENT Olioperustainen ohjelmistokehitys Olioperustaisuus (object oriented) järjestelmä (system) muodostuu joukosta olioita (object), jotka yhteistyössä toimien tuottavat järjestelmän palvelut. Olio on kokonaisuus (entity), joka kykenee suorittamaan omaan tietämykseensä (information contents) perustuvia palveluita (service / operation / method) Olioperustainen ohjelmistokehitys Olio voidaan nähdä abstraktiona, jota voidaan soveltaa eri tilanteissa eri tavoin: Olio-ohjelmoinnissa: ohjelman suoritus etenee tietokoneen sisuksissa toimivien tietojenkäsittelyolioiden yhteistyön tuloksena olioiden palvelut ovat suorituksen askelia Tietojärjestelmän palvelut saadaan aikaan suorittamalla ohjelmia Tietojärjestelmän palvelut ja olio-ohjelmointi Olioiden yhteistyö ohjelmassa tietojärjestelmä Palvelu tuottaa Ohjelman suoritus toteutuu Ohjaa suoritusta Olio 1 Palvelu a tietää Olio 3 Palvelu b Ohjelmaolioiden yhteistyönä Olio 2 Käyttää apuna Olio 4 Palvelu d Palvelu c Tietojärjestelmän palvelun suoritus ohjelmassa Liiketoiminta olioiden yhteistyönä tj Ohjaa suoritusta Palvelu a Olio 1 tietää Palvelu b Olio 3 Toisena ääripäänä liiketoiminta voidaan myös hahmottaa liiketoiminnan osapuolten (jälleen olioita) välisenä yhteistyönä - yleensä liiketoiminnan osapuolina ovat organisaatioyksiköt ja henkilöt Palvelu d Olio 2 Käyttää apuna Palvelu c Olio 4 Harri Laine 1
Liiketoiminnan osapuolten yhteistyötä Tietojärjestelmä avustavana oliona Virkailija Virkailija Vastaanota tilaus Vastaanota tilaus Asiakas toimitus varasto Asiakas toimitus varasto varastojärjestelmä käyttää Tilauksen vastaanotto Tee kuormakirja Olioperustainen kuvaaminen Tietojärjestelmä ja sen ympäristö voidaan siis hahmottaa erilaisen olioiden yhteistyön avulla. Miten tämä sitten pitäisi kuvata? Mikä on oleellista ja välttämätöntä Eri menetelmät korostavat eri asioita, tärkeänä voidaan pitää: oliorakennetta, yhteistyötä, olioiden elinkaarta, järjestelmän käyttöä, tiedon kulkua, Kuvausjärjestelmät enimmäkseen graafisia: yksi kuva kertoo enemmän kuin 1000 sanaa UML UML (unified modeling language) on kokoelma käsitteitä ja kaaviotekniikoita oliokeskeiseen järjestelmäkehitykseen Yhdistelmä hyviksi havaituista (of best practices) tekniikoista OMT+Booch+OOSE Rumbaugh, Booch, Jacobson http://www.rational.com/ UML UML Kehitetty Rational Software Corp. toimesta 1996 -> OMG:n (Object Management Group) valinta kuvaustekniikaksi (viimeisin versio 1.3 heinäkuu 99) OMG on olioteknologian kehittämiseen tähtäävä yritysten perustama organisaatio - tuotoksia mm. CORBA-teknologia Useat CASE- välineet (Computer Aided Software Engineering) tukevat tai ovat siirtymässä tukemaan UML sisältää: metamallin, jolla määritellään varsinainen kuvausjärjestelmä, UML-mallit peruskäsitteet, käsitteiden väliset yhteydet, säännöt, laajennettavuus kokoelman graafisia kuvaustekniikoita eri tarkoituksiin Harri Laine 2
tuottaa Kuvaustekniikka Käsitteet ja esitystapa Kuvaustekniikka ja metamalli Tekniikan laatiminen ohjaa ohjaa Kuvauksen laatiminen metamalli Mallin periaatteet ja laajennettavuus tuottaa kuvaus UML-tekniikat UML-kuvaustekniikat Käyttötapausmalli (use case model) kuvaa mitä järjestelmällä tehdään Luokkakaavio ja oliokaavio (class/object diagram) tiedot ja mitä niille/niillä tehdään Tilakaavio (statechart diagram) olioiden elinkaaret tilakoneina UML-tekniikat Olioiden yhteistyökaaviot palveluketjut (sequence diagram) yhteistyörakenteet (collaboration diagram) Kummatkin kuvaavat sitä kuinka toiminta hoidetaan olioiden välisenä yhteistyönä. Toimintoketjuissa korostuu olioiden palvelujen hyväksikäyttö. Yhteistyörakenteissa olioiden välisten kytkentöjen hyödyntäminen yhteistyön perustana. UML-tekniikat Komponenttikaavio (component diagram) ohjelmiston koostuminen komponenteista Sijoittelukaavio (deployment diagram) ohjelmiston osien sijoittuminen tietoverkkoon Molemmat voidaan ajatella erikoistuneisiin olioihin perustuvina oliokaavioina Aktiviteettikaavio (activity diagram) kontrollin kulku prosessissa tai ohjelman operaatiossa haarautumat, workflow Luokka- ja oliokaaviot Luokka- ja oliokaavioilla kuvataan ohjelmiston / järjestelmän koostuminen olioista, olioiden tietämys, niiden tarjoamat palvelut sekä olioiden väliset yhteydet Olio tiedon ja sen käsittelyyn liittyvien palveluiden muodostama kokonaisuus olio pitää sisällään tietoja, joita olion palvelut käsittelevät / hyödyntävät Puhtaassa olio-ohjelmoinnissa olion tietoihin pääse käsiksi vain olion palveluiden kautta Luokka- ja oliokaaviot (Olio)luokka (class, object class) on samankaltaisten olioiden malli Saman mallin mukaiset oliot kuuluvat samaan luokkaan. Ne ovat kyseisen luokan ilmentymiä (instance). Luokkakuvaus määrittelee luokan. Harri Laine 3
Reaalimaailma ja luokka Olio-ohjelma ja luokka luokka eläin ilmentymät public class elain { int elain_numero; String laji; Color vari; float paino; Luokkakuvaus ohjelmointikielellä Eläin on.. määrittelee Ominaisuuksia: paino, väri, sukupuoli,... Toimintoja: syöminen, liikkuminen,... luokkakuvaus public elain( ){ } public setpaino( ){ } public float getpaino(){ } } elain otus = new elain(.); elain toinen = new elain(.); ilmentymä 1 ilmentymä 2 Luokkakuvaus UML:llä Ilmentymän kuvaaminen elain elain_numero: int laji: String vari: Color paino: float +elain( ) +setpaino( ) +getpaino(): float * * laji vari 1 1 String Color Otus1: elain elain_numero=12345 laji=norsu vari=harmaa paino=2300 Otus2: elain elain_numero=12346 laji=aasi vari=ruskea paino=220 Instance of Instance of Ilmentymiä esitetään yleensä vain esimerkkeinä otus: elain toinen: elain Pitäisi oikeastaan poistaa täältä toisteisina Luokkakuvaus UML:ssä välttämätön mukana tarvittaessa nimi attribuutit palvelut Olioiden tietämys (tietosisältö) kuvataan attribuutteina Attribuutista voidaan esittää nimi (välttämätön) tietotyyppi arvojen määrä (hakasuluissa, alaraja..yläraja, *=epämääräisen monta) näkyvyys vain ohjelmointiläheisessä kuvauksessa oletusarvo muita määreitä Harri Laine 4
Näkyvyys (visibility) on esim. C++ ja Javaohjelmointikielissä käytetty tekniikka, jolla säädellään luokkakuvauksessa esitellyn muuttujan tai metodin (palvelun) käyttöä. private (#) rajaa käytön luokan omiin palveluihin protected (-) sallii käytön luokan aliluokissa määriteltävissä palveluissa puhdasoppisesti ajateltuna kaikkien attribuuttien tulisi olla näkyvyydeltään protected public (+) sallii käytön myös luokan ulkopuolelta UML käyttää yllä sulkeissa olevaa merkkiä attribuutin nimen edessä osoittamaan näkyvyyden #numero #n_tila -tapahtumat[*] +viimeeksi_käytetty_pvm Attribuutit numero ja n_tila ovat käytettävissä suoraan luokan palveluissa (esim. annatilinumero,annatilityyppi, lopeta, sulje) Moniarvoiseen attribuuttiin tapahtumat voi viitata n aliluokissa esim. luokassa käyttö. Atribuuttiin viimeeksi_käytetty voi viitata myös ulkopuolisten luokien palveluissa UML:ssä on mahdollista määritellä luokka-attribuutteja (class attribute), luokkakohtainen arvo ilmaistaan alleviivaamalla attribuutin nimi ilmentymäattribuutteja (instance attribute) arvo erikseen jokaisessa luokan ilmentymässä henkilötunnus #tarkistusmerkit[31] #päiväys #jnro #tarkmerkki Luokkakohtainen tarkistusmerkkitaulukko Ilmentymäkohtaisia osasia Attribuutin arvo on jotain tyyppiä. Tyyppi ilmaistaan antamalla se nimen perässä kaksoispisteellä erotettuna päiväys:date jnro:int tarkastusmerkki: char Arvo voi olla perustietotyyppin arvo UML ei ota kantaa tietotyyppeihin vaan sallii mitä tahansa perustietotyyppejä yllä int ja char Olio, jolloin tietotyyppinä on olion luokka Olioarvoinen attribuutti muodostaa yhteyden attribuutin sisältävän olion ja attribuutin arvona olevan olion välille. Tällaiset yhteydet pitäisi tuoda selkeästi esiin ja kuvata omalla tekniikallaan (luokkia yhdistävinä viivoina) Jos attribuutin arvona on olio tämä tulisi esittää attribuuttimäärittelyn yhteydessä vain mikäli olion luokka on perustietotyyppimäinen, esim Date, String, Color, Point, päiväys:date nimi:string Attribuuttimäärittelyyn voi liittää muiden määrittelyjen jälkeen kaarisulkeissa {...} lisämääreitä UML tarjoaa valmiina lisämääreet changeable (oletus) arvon muuttamiseen ei ole rajoitteita frozen arvoa ei voi muuttaa addonly moniarvoiselle attribuutille voi vain lisätä arvoja ei koskaan poistaa Harri Laine 5
UML-mallin soveltaja voi ottaa käyttöön omia lisämääreitä. Hyödyllisiä voisivat olla id ulkoinen tunniste, attribuutin arvo ei voi olla sama kahdella eri ilmentymällä ja Java ohjelma UML-luokka vastaa Java-luokkaa. Static-muuttujat vastaavat luokka-attribuutteja muut luokassa määritellyt muuttujat vastaavat ilmentymäattribuutteja numero {frozen, id} Tilinumeroa ei voi muuttaa, se yksilöi t Luokan palvelut Luokan palvelut Palvelusta UML:ssä voidaan kuvata näkyvyys - kuten attribuuttien kohdalla nimi (välttämätön) parametrit paluuarvon tyyppi muut määreet [näkyvyys] nimi [(parametrit)] [:paluuarvon tyyppi] [{muut määreet}] parametrimäärittelyn muoto on [suunta] nimi: tyyppi [= oletusarvo ] Esim. henkilötunnus #tarkistusmerkit[31] #päiväys #jnro #tarkmerkki +tostring():string +isok():boolean +getbirthdate():date +getsex():int Olioiden (ilmentymien) välisiä rakenteellisia kytkentöjä kutsutaan yhteyksiksi (association) Ohjelmakoodissa rakenteellinen kytkentä ilmenee siten, että luokalla on olioarvoinen attribuutti tai jokin epäsuora viittaus toiseen olioon. Omistaja[*]:Asiakas Tarkoittaa, että -olioiden ja -olioiden välillä on kytkentä, joka voidaan kuvata seuraavasti: Omistaja-> * Yhden n voi omistaa useita asiakkaita Harri Laine 6
Oletetaan, että Java-ohjelmassa n omistaja olisi määritelty seuraavasti Asiakas[] Omistaja = new Asiakas[3]; eli llä voi olla enintään 3 omistajaa. Pankkillä täytyy aina olla omistaja (tämä on Java-ohjelmassa tarkistettava ohjelmassa) Ylläoleva esitettäisiin: Edellä on kyseessä suunnattu yhteys: stä päästään asiakkaaseen, mutta asiakkaasta ei päästä in, eli ilmentymätasolla tilanne olisi 1234: Omistaja-> 1..3 omistaja omistaja Aku Ankka:Asiakas Ines Ankka:Asiakas Jos haluttaisiin yhteys myös toiseen suuntaan (ja edelleen taulukoilla), voisimme määritellä asiakkaalle attribuutin [] =new [10]; Omistaja-> 1..3 Ilmentymätasolla tilanne voisi olla 1234: 1235: omistaja omistaja 1236: 0..10 <-Tili 4567: Aku Ankka:Asiakas Ines Ankka:Asiakas Koska asiakkaalla ei välttämättä ole yhtään ä Kun huomaamme, että kyseessä ja omistaja yhteydet kuvaavat samaa asiaa voimme yhdistää ne. Ilmentymätasolla mikään ei muutu 0..10 Omistaja-> 1..3 <-Tili Harri Laine 7