Ohjelmistojen mallintaminen Ohjelmiston suunnittelu Model driven development 2.12.2008 Harri Laine 1
Jacobson jakaa ohjelmiston oliot kolmeen tyyppiin liittymäolioiksi (interface objects, boundary objects) - toteuttavat ohjelmiston (käyttö)liittymän - kommunikointi käyttäjien tai oheislaitteiden kanssa kontrolliolioiksi (control objects) - ohjaavat ajoaikaista toimintaa sisältöolioiksi (entity objects) - edustavat tallennettua tietosisältöä ja vastaavat käyttöliittymästä ja kontrollista riippumattomista palveluista 2.12.2008 Harri Laine 2
Olioiden jaottelu tyyppeihin auttaa suunnittelijaa jäsentämään kokonaisuutta ja sijoittamaan palveluja olioille. Esimerkiksi tietosisältöön liittyvää loogisuustarkistusta ei ole syytä sijoittaa liittymäolion palveluiksi, vaan tarkistus sopii paremmin tietosisällöstä vastaavan sisältöolion palveluksi. Käyttötapaukseen liittyvän monimutkaisen työnkulun valvonta olisi parempi antaa erillisen ohjausolion tehtäväksi kuin yrittää upottaa sitä väkisin käyttöliittymäikkunan tai sitä vastaavan sisältöolion vastuulle. Olioiden jaottelu kategorioihin on eräänlainen karkean tason ratkaisumalli. 2.12.2008 Harri Laine 3
Oliopohjaisessa kehittämisessä määrittelyn ja suunnittelun raja on epäselvä - useita iteraatioita eri tarkkuustasoilla määrittelyn yhteydessä on laadittu käyttötapausmalli mahdollisesti aktiviteettikaavioita tarkentamaan toiminnan kuvausta luokkamalli (palvelujen määrittely hyvin karkeaa, jos mukana) mahdollisesti elinkaarimalleja hahmoteltu käyttöliittymää (ei käsitelty tällä kurssilla) kuvattu riippuvuuksia (käyttötapaus- käyttöliittymä, käyttötapaus - sisältö) 2.12.2008 Harri Laine 4
Siirryttäessä suunnitteluun Tehdään alustava päätös arkkitehtuurimallista ja sen myötä osajärjestelmiin jaosta Luokkamallia tarkennetaan arkkitehtuuriratkaisun roolit huomioiden 2.12.2008 Harri Laine 5
Suunnittelun eteneminen käyttötapauskohtaisesti Kullekin käyttötapaukselle (tai jos käyttötapauksia on yhdistetty niiden pakkaukselle) vähintään yksi liittymäluokka Kullekin käyttötapaukselle määritellään vähintään yksi kontrolliluokka, jolle annetaan päävastuu käyttötapauksen läpiviennistä Otetaan mukaan apuluokkia sitä mukaa kuin niille ilmaantuu tarve 2.12.2008 Harri Laine 6
Mallin täydennyksessä edetään palvelujen määrittelyn kautta proseduraalinen kontrolli lähdetään liikkeelle käyttötapauksen aktiviteettimallista ja sijoitetaan aktiviteetteja vastaavat palvelut luokille tapahtumapohjainen kontrolli lähdetään liikkeelle käyttötapauksen elinkaarimallista ja määritellään siirtymiä vastaavat tapahtumakäsittelijät palveluiksi 2.12.2008 Harri Laine 7
Tarkastellaan esimerkkinä sukututkimusaineiston raportointisovellusta tutkija descendant_report selected_persons compare_files Aineistot ovat gedcom-standardi muodossa olevina tiedostoina. Aineistojen muodostus ja muokkaus hoidetaan eri sovelluksella 2.12.2008 Harri Laine 8
sisältömalli + kapseloivat liittymämetodit 2.12.2008 Harri Laine 9
Arkkitehtuuriratkaisu käyttötapaukset ovat kaikki raportteja, näiden muodostus voidaan jakaa vaiheisiin sisällön muodostus ulkoasun muotoilu jos sisältö annetaan XML-muodossa on tarjolla valmiita työkaluja muotoilun määrittelyyn - käytetään niitä ratkaisuksi sopisi siis putket ja suodattimet. XMLtyökalut saattavat edellyttää, että koko aineisto on valmis - tyydytään tähän 2.12.2008 Harri Laine 10
Käyttöliittymä voitaisiin toteuttaa ikkunana, jossa voi valita raportin tyypin, määritellä syöttötiedostot ja nimetä tulosaineiston. Ensimmäisessä prototyypissä annetaan syöttötiedot komentoriviargumentteina. 2.12.2008 Harri Laine 11
otettu mukaan liittymä- ja kontrolliolioita 2.12.2008 Harri Laine 12
Rakenteen luontimetodit 2.12.2008 lisätty Harri Laine 13
Luonnin idea: Raportointia kontrolloiva olio luo GEDCOMFile olion ja välittää sen argumenttina Lineage-konstruktorille. Konstruktori käy silmukassa läpi tiedoston ja luo elementin vaihtuessa Person tai Family olioita (huom. Person data on aineistossa ennen Family dataa). Person ja Family data muodostuu useasta rivistä. Lineage päättelee kuuluuko rivi vielä samaan kohteeseen jota ollaan tekemässä ja jos kuuluu antaa rivin kohteen käsiteltäväksi. Onko tämä hyvä malli? 2.12.2008 Harri Laine 14
Iteraation tuloksena uusi versio: Raportointia kontrolloiva olio luo Lineage-olion ja välittää konstruktorille tiedostonimen. Konstruktori luo tiedoston ja käy silmukassa läpi tiedoston ja luo elementin vaihtuessa Person tai Family olioita (huom. Person data on aineistossa ennen Family dataa). Person ja Family data muodostuu useasta rivistä. Lineage päättelee kuuluuko rivi vielä samaan kohteeseen, jota ollaan tekemässä, ja jos kuuluu antaa rivin luotavan kohteen käsiteltäväksi. 2.12.2008 Harri Laine 15
2.12.2008 Harri Laine 16
Paritukseen tarvittavia metodeja ja niiden apurakenteita lisätty 2.12.2008 Harri Laine 17
Esimerkin tapauksessa Family ja Person luokilla on samankaltaisia operaatioita. Lineage olion kannalta voisi luontivaiheessa olla yksinkertaisempaa, jos Family ja Person näkyisivät samankaltaisina. Kannattaisi siis harkita yleistysluokan lisäämistä malliin ja osan attribuuteista ja operaatioista siirtämistä sinne. Suunnittelun edetessä pitäisi vielä ratkaista kokoelmien toteutustapa, määritellä XML-rakenne ja laatia metodit xml:n tuottamiselle Onko paritusoperaatioiden oikea paikka sittenkään kontrollioliossa? 2.12.2008 Harri Laine 18
Compare_files Lineage1 Lineage2 Person1 Person2 LastName matchperson Person.byID(id1) Person.byID(id2) likeness getlastname getlastname compare 2.12.2008 Harri Laine 19
a teettää b c tekee Kuinka? Law of Demeter Parempi a:lle ei tarpeetonta tietoa a teettää b getc c tekee a teettää b välitää c tekee a b c getc a b c välittää 2.12.2008 Harri Laine 20
postinkantaja kuljetaposti (posti, paikka) opettaja posti paikka omavahtimestari lähetä (posti, Paikka) vahtimestari postimies getpostimies( ) postinkantaja getpostimies () { return postimies; } lähetä(posti,paikka) { postinkantaja kantaja; kantaja = omavahtimestari.getpostimies; kantaja.kuljetaposti(posti,paikka); } 2.12.2008 Harri Laine 21
postinkantaja kuljetaposti (posti, paikka) opettaja posti paikka omavahtimestari lähetä (posti, paikka) postimies vahtimestari toimitaposti (posti, paikka) toimitaposti () { postimies.kuljetaposti(posti,paikka); } lähetä(posti,paikka) { omavahtimestari.toimitaposti(posti,paikka); } 2.12.2008 Harri Laine 22
Mallikeskeinen ohjelmistokehitys Mallikeskeisen ohjelmistokehityksen perusajatuksena on kuvata ohjelmisto sarjana abstraktiotasoltaan tarkentuvia malleja Käytettävät mallit ja niiden käsitteistö ovat kohdealuekohtaista (e-kaupan malli, tietoliikkennesovellusmalli, pelimalli, ) Kehittäminen tapahtuu mallimuunnosten kautta esim. pelimallista komponenttimalliin Mallimuunnokset pyritään automatisoimaan, lopullinen tulos suoritettava ohjelma 2.12.2008 Harri Laine 23
Mallikeskeinen ohjelmistokehitys /MDA Model driven architecture (MDA) on Object management group:n (OMG) esittelemä kehittämismalli, jossa käytettään OMG:n standardoimia malleja MOF-metamallilla kuvattavissa olevia malleja, UML ja sen profiilit OCL object constraint language täsmälliseen määrittelyyn 2.12.2008 Harri Laine 24
Mallikeskeinen ohjelmistokehitys /MDA Vapaamuotoisia Erityiskielellä esitetty korkean abstraktiotason malli Alemman abstraktiotason toteutusalustariippuva malli ohjelmakoodi 2.12.2008 Harri Laine 25
Mallikeskeinen ohjelmistokehitys /MDA Platform independent model (PIM, alustariippumaton malli): malli ei (joltain kannalta katsottuna) ota kantaa toteutustekniikkaan Platform specific model (PSM, alustariippuva malli): toteutusalusta kiinnitetty (alustan monitasoisuus) PIM PSM / PIM PSM Kerroksia Toisen PIM on toisen PSM 2.12.2008 Harri Laine 26
Mallikeskeinen ohjelmistokehitys /MDA Alusta voisi olla esimerkiksi käyttöjärjestelmätason ratkaisu, komponenttitekninen perusratkaisu (esim. CORBA/EJB), yleinen arkkitehtuurimalli Mallit kohdealuekohtaisia ja kohdealuekohtaiseen käsitteistöön (metamalliin) perustuvia (esim. UML profiilit) Mallien täytyy olla hyvin määriteltyjä ja täsmällisiä 2.12.2008 Harri Laine 27
Mallikeskeinen ohjelmistokehitys /MDA Mallien väliset muunnokset pyritään automatisoimaan Muunnoskuvaukset määrittelevät mallien välisen muunnoksen Tarvitaan kieli muunnosten kuvaamiseen 4g kielet soveltuvat kohteiksi 3g kieliä paremmin, samoin kootut komponentit (asennuskuvausten generointia) 2.12.2008 Harri Laine 28