Ohjelmistotuotanto Ohjelmistosuunnittelu 2 1. Käyttötapalähtöinen suunnittelu Lähtökohdat: käyttötapamalli (käyttötapaukset, use cases), määrittelytason luokkakaavio Tehtävät: 1. Käyttöliittymän periaatesuunnittelu Mitkä käyttötapaukset hoidetaan saman käyttöliittymän kautta? Ulkoasu, look and feel Periaateratkaisu käyttöliittymän ja sovelluslogiikan suhteista miten käyttöliittymä erotetaan sisältöluokista arkkitehtuuri (MVC / komennot /.) Käytettävä liittymäkirjasto Syntyy liittymäluokkia, jotka vastaanottavat syötteitä ja välittävät tuloksia 1 Harri Laine, Jukka Paakki 2 Käyttötapalähtöinen suunnittelu 2. Tietojen säilytykseen liittyvät periaateratkaisut tiedostot, tietokannat, ohjelman ja tietokannan kommunikointi -kerrostus, eristäminen kirjastot sisältöluokat määrittelytason luokkien pohjalta 3. Hajautukseen ja tietoliikenteeseen liittyvät periaateratkaisut sanomanvälitys, kirjastot Käyttötapalähtöinen suunnittelu 4. Käyttötapausten läpikäynti: 4.1. Ratkaise, miten käyttötapaus hoituu käyttäjän kannalta 4.2. Ratkaise käyttötapauksen kulku järjestelmän kannalta osallistuvat oliot, luokat, palvelut, attribuutit olioiden yhteistyö - mitä palveluja käytetään lisää tarvittaessa palveluita, luokkia ja attribuutteja, jotta saat yhteistyön sujumaan simuloi käyttötapausta luokkamallin suhteen Harri Laine, Jukka Paakki 3 Harri Laine, Jukka Paakki 4 Käyttötapalähtöinen suunnittelu Pitäisi saada aikaan tietty toiminto Minkä olion vastuulla toiminto on? luokka, olio; lisää tarvittaessa Onko luokalla jo tarvittava palvelu? lisää tarvittaessa Onko oliolla tarpeellinen tietosisältö palvelun hoitamiseksi? lisää tarvittaessa attribuutteja, yhteydet muihin olioihin Hoitaako olio palvelun yksinään vai tarvitaanko yhteistyötä? mahdollista yhteistyö; vain tunnettujen olioiden palveluita voi käyttää Käyttötapalähtöinen suunnittelu 4.3. Tehdyt muutokset voivat vaikuttaa aiemmin tehtyihin ratkaisuihin - iteroi 5. Täsmällinen kuvaus luokista, attribuuteista ja palveluista 6. Pakkausten, osajärjestelmien yms. määrittely Hyödynnä standardoituja ratkaisumalleja ja olemassa olevia kirjastoluokkia Harri Laine, Jukka Paakki 5 Harri Laine, Jukka Paakki 6 1
(UML): Sekvenssikaavio (yhteistyöpolut) (sequence diagram) Keskitytään erityisesti kuvaamaan operaatioiden tapahtumajärjestystä ja toimintaan liittyvien viestien kulkua. Sekvenssikaavion toinen ulottuvuus on aika. Yhteistyörakennekaavio (collaboration diagram) Keskitytään kuvaamaan sitä, miten yhteistyö hyödyntää olioiden välisiä kytkentöjä. Viestien ajallinen kulku merkittävä kaavioon erikseen. Sekvenssikaavio Kuvaa, miten kontrolli ajallisesti etenee oliolta toiselle jotain toimintoa (esim. käyttötapausta) suoritettaessa mitä olioita palvelun suoritukseen osallistuu ja mitä näiden palveluja käytetään missä järjestyksessä olioiden palveluita käytetään Harri Laine, Jukka Paakki 7 Harri Laine, Jukka Paakki 8 operaatio / palvelu palkin pituus kuvaa palvelun kestoa olio1:luokka [ehto] viesti (parametrit) olio2:luokka nimeää käytettävän palvelun aika Viestit ovat yleensä palvelujen kutsuja (palvelupyyntöjä) palvelun nimi (ja parametrit) käytännössä metodikutsu olio-ohjelmassa ehto ei ole välttämätön palveluun liittyvä paluunuoli jätetään yleensä piirtämättä, vaikka palaute saataisiinkin (kaavio tulee näin yksinkertaisemmaksi) Harri Laine, Jukka Paakki 9 Harri Laine, Jukka Paakki 10 class A { B oliob; C olioc; D oliod; public int doit() { oliob.assist1(); olioc.assist2(oliod); class D {. public serviced { class B { E olioe; public void assist1() { olioe.dosomething(); class C {. public void assist2(d od){ od.serviced() doit olioa:a oliob:b olioe:e olioc:c oliod:d assist1() dosomething assist2(oliod); serviced Harri Laine, Jukka Paakki 11 Harri Laine, Jukka Paakki 12 2
Luonti ja tuhoaminen SILMUKAT Palvelua pyydetään useilta olioilta use create :Apuluokka Saman palvelujonon toisto olio1 olio2 olio3 * palvelu delete * koottu Harri Laine, Jukka Paakki 13 Harri Laine, Jukka Paakki 14 Yhteistyöketjuja käytetään havainnollistamaan oliorakenteen toimintaa ei kannata laatia jokaiselle palvelulle / käyttötapaukselle, vaikka jokaisen kohdalla yhteistyö on mietittävä laaditaan keskeisille palveluille ja tilanteisiin, joissa kaavioiden käyttö edistää suunnitelman ymmärtämistä 3-4 viestiä pidemmät ketjutpikemminkin sotkevat kuin havainnollistavat 2. Hyvä oliorakenne Oliorakennetta suunniteltaessa pitäisi pyrkiä minimoimaan olioiden välisiä yhteyksiä (kytkentää) olio 'tuntee' mahdollisimman vähän muita olioita ja näiden luokkia olion tarvitsee käyttää mahdollisimman vähän muiden olioiden palveluja (kiinteys, cohesion) palvelujen käyttöön liittyvät sanomat ovat mahdollisimman yksinkertaisia Harri Laine, Jukka Paakki 15 Harri Laine, Jukka Paakki 16 Hyvä oliorakenne? Hyvä oliorakenne postinkantaja kuljetaposti (posti, paikka) opettaja posti paikka omavahtimestari postinkantaja kuljetaposti (posti, paikka) opettaja posti paikka omavahtimestari lähetä (posti, paikka) lähetä (posti, paikka) vahtimestari postimies vahtimestari postimies getpostimies( ) postinkantaja getpostimies () { return postimies; lähetä (posti,paikka) { postinkantaja kantaja; kantaja = omavahtimestari.getpostimies; kantaja.kuljetaposti(posti,paikka); toimitaposti (posti, paikka) toimitaposti () { postimies.kuljetaposti(posti,paikka); lähetä (posti,paikka) { omavahtimestari.toimitaposti(posti,paikka); Löyhä paikallinen kytkentä: tämä on parempi! Harri Laine, Jukka Paakki 17 Harri Laine, Jukka Paakki 18 3
Hyvä oliorakenne Hyvä oliorakenne vaihtoehto 1 opettaja vahtimestari postinkantaja getpostimies kuljetaposti Perinnän ja dynaamisen sidonnan hyödyntäminen Tarkastellaan ohjelmaa, jonka tehtävänä on tuottaa erilaisista kuvioista muodostuva kuvaesitys Ratkaisu 1: perinteinen malli - ei perintää laajentaminen edellyttää luokan Kuvio muuttamista vaihtoehto 2 toimitaposti kuljetaposti Kuvio Tyyppi Piirrä if Tyyppi= ympyrä then piirrä_ympyrä(.) else if Tyyppi= suorakaide then piirrä_suorakaide(.) else. Harri Laine, Jukka Paakki 19 Harri Laine, Jukka Paakki 20 Hyvä oliorakenne Perintää ja syrjäyttämistä hyödyntävä. Uusia muotoja voidaan lisätä helposti. Kuvion muoto määräytyy luonnin yhteydessä. Ympyrä Piirrä Kuvio Piirrä: abstract Suorakaide Piirrä Uusimuoto Piirrä Hyvä oliorakenne Erillinen algoritmi, jolle toiminta ohjataan: muotoa voidaan vaihtaa dynaamisesti lennossa Kuvio piirtotapa piirrä Piirtotapa piirtele ympyrä suorakaide piirrä_ympyrä piirrä_suorakaide uusitapa piirtotapa.piirtele() uusitapa Harri Laine, Jukka Paakki 21 Harri Laine, Jukka Paakki 22 3. Ratkaisumallit Edellisellä kalvolla oli esimerkki suunnittelutason ratkaisumallista (Strategy), joka lisää joustavuutta ja muunneltavuutta järjestelmään. Esim. UML-kaavioiden laatimisohjelma, jossa käyttäjä saisi määritellä omat kuvasymbolinsa, voisi käyttää tätä ratkaisumallia (tai jotain vielä paremmin soveltuvaa). Ratkaisumallit Ratkaisumallit (patterns) ovat systemaattisia hyviksi havaittuja tapoja ratkaista tietty usein esiintyvä ongelma taitotiedon, kokemuksen dokumentti yleiskäyttöisiä ratkaisumalleja sovellusaluekohtaisia ratkaisumalleja Ratkaisumalleja voi liittyä kehittämisprosessiin (process pattern) määrittelyvaiheen ongelmiin (analysis pattern) suunnitteluvaiheen ongelmiin (design pattern) ohjelmointitason ongelmiin (idiom) Harri Laine, Jukka Paakki 23 Harri Laine, Jukka Paakki 24 4
Ratkaisumallit Analyysimallit (analysis patterns) Kuinka jäsentäisi ongelman, jotta saavutettaisiin joustavuutta/muunneltavuutta/.? Suunnittelumallit (design patterns) Kuinka ongelma olisi hyvä ratkaista teknisesti, jotta saavutettaisiin joustavuutta / muunneltavuutta / ylläpidettävyyttä / tilansäästöä / toimivuutta / siirrettävyyttä Idiomit (idioms) Kuinka asia pitäisi ratkaista esim. Javalla Ratkaisumallit Parantelumallit eli anti-mallit (anti-patterns) Normaalisti ratkaisumalleissa kuvataan ongelma ja esitetään siihen ratkaisutapa. Parantelumalleissa lähtötilanteena on se, että jotain on jo tehty tavalla, joka aiheuttaa ongelmia. Mallit esittävät ratkaisutavan, jolla päästään nykyistä parempaan ratkaisuun. Parantelumalli = huono ratkaisu usein esiintyvään ongelmaan + ohjeet huonon ratkaisun muuttamiseksi hyväksi (esim. ratkaisumallin mukaiseksi) Harri Laine, Jukka Paakki 25 Harri Laine, Jukka Paakki 26 Ratkaisumallit Tunnetuin lähde: E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns - Elements of Reusable Object- Oriented Software, Addison-Wesley, 1995 esittelee 23 ohjelmista etsittyä olioperustaista suunnittelumallia Seuraavaksi käydään läpi muutama esimerkki yllä mainitun lähteen ratkaisumalleista Ratkaisumallit Kooste (Composite) Tarkoitus: Kokonaisuuden ja sen osien käsitteleminen samalla tavalla Esimerkki: piirto-ohjelmassa kuvio voi koostua hierarkkisesti pienemmistä osakuvioista, ja halutaan piirtää kaikki kuvioelementit samalla tavoin (ts. samannimisellä operaatiolla hyödyntäen olioohjelmoinnin monimuotoisuutta ja dynaamista sidontaa) Harri Laine, Jukka Paakki 27 Harri Laine, Jukka Paakki 28 Ratkaisumallit Kooste (Composite) Client Leaf Operation( ) foreachc in children c.operation Component Operation () : abstract Add (Component) Remove (Component) GetChild (int) * Composite children Operation () Add (Component) Remove (Component) GetChild (int) Harri Laine, Jukka Paakki 29 Ratkaisumallit Kooste (Composite) Määritellään abstrakti luokka, jonka konkreettisina aliluokkina(siis sellaisina, joilla on ilmentymiä) ovat alkeisluokat ja kokoelmat. Palvelut määritellään abstraktin luokan tasolla. Palvelut jakautuvat kokoelman hallintapalveluihin ja varsinaisiin palveluihin. Kokoelman varsinaiset palvelut suoritetaan välittämällä pyyntö kokoelman osille. Esimerkiksi abstrakti luokka voisi olla kuvio ja sen aliluokat olisivat alkeiskuvio ja koottu_kuvio. Varsinainen palvelu olisi piirrä. Kootun kuvion piirrä -palvelu toteutetaan kutsumalla kunkin sen osan piirrä -palvelua. Harri Laine, Jukka Paakki 30 5
Ratkaisumallit Kooste (Composite) Ratkaisumallit Kooste (Composite) Leaf1 Composite1 Composite2 Leaf2 Composite1.children Ratkaisun etunaon se, että asiakas pystyy käsittelemään myös koosteoliota missä tahansa yhteydessä, jossa se käsittelee alkeisoliota Haittana on se, että kaikki koosteoliot ovat rakenteeltaan samanlaisia (ei voi olla eri tavoin käsiteltäviä, täysin erilaatuisia osia) Leaf3 Leaf4 Leaf5 Composite2.children Harri Laine, Jukka Paakki 31 Harri Laine, Jukka Paakki 32 Ratkaisumallit Tarkkailija (Observer) Ratkaisumallit Tarkkailija (Observer) Tarkkailija (Observer) esittää tavan välittää olion tilan muuttuminen tästä riippuville olioille ilman, että olioiden välillä olisi kumpaankin suuntaan vahvaa kytkentää. Kaksi roolia, kohde ja tarkkailija. Tarkkailija (Observer) rekisteröityy tarkkailemaan kohdetta (Subject). Kohde tiedottaa muutoksesta kaikille rekisteröityneille tarkkailijoilleen. Saatuaan ilmoituksen tarkkailija selvittää kohteen tilan. Abstract Subject Observers[] Join() Detach() Notify() Concrete Subject State getstate() setstate() Heikko kytkentä forall Observers update() Observer update() Concrete Observer subject update() Harri Laine, Jukka Paakki 33 Vahva kytkentä subject.getstate Harri Laine, Jukka Paakki 34 Ratkaisumallit Tarkkailija (Observer) Rekisteröityminen Ratkaisumallit Tarkkailija (Observer) Observer Join() Subject Subject setstate Observer Notify * update getstate Harri Laine, Jukka Paakki 35 Vahva kytkentä Harri Laine, Jukka Paakki 36 6
Ratkaisumallit Tarkkailija (Observer) Ratkaisumallit Tarkkailija (Observer) Käyttötilanteita käyttöliittymän näkymä - kohde taulukon (taulukkolaskimen) johdettu alkio - perusalkio Laskentataulukko: viewa A B C=A+B cella Nuolet osoittavat tarkkailtavaan viewb cellb viewc cellc Harri Laine, Jukka Paakki 37 Harri Laine, Jukka Paakki 38 Ratkaisumallit Tarkkailija (Observer) Vaaroja: Tarkkailija saa useita ilmoituksia saman kohteen muutoksista - turhia päivityksiä esim. jos kohdeluokan erikoistamiseen ei ole varauduttu, voi malli aiheuttaa useita ilmoituksia kohde muutos uusikohde muutos do_it(); notify() super.muutos(); omat_hommat(); notify() Ilmoitetaan keskeneräisestä tilasta Ratkaisumalli Tehtaat (Factory-mallit) Olioiden luominen on oliomalleissa ongelmallinen tehtävä olion toiminnallisuus määräytyy sille luontihetkellä annetun konkreettisen luokan perusteella konkreettiset luokat eivät ole tiedossa kirjastoa laadittaessa - miten siis kirjaston pitäisi huomioida luonti? erityiset luontiluokat, joilla abstraktit luontipalvelut luontipalvelut konkretisoidaan luontiluokkien aliluokissa Harri Laine, Jukka Paakki 39 Harri Laine, Jukka Paakki 40 Ratkaisumalli Abstrakti tehdas (Abstract Factory) Abstract Factory: olioiden luontiin liittyvä olioiden välisiä suhteita hyödyntävä malli Tarkoitus: malli esittää tavan luoda tietyn luokan jälkeläisluokkien ilmentymiä tuntematta näitä luokkia Esimerkki: yleiskäyttöinen käyttöliittymäkirjasto Käyttöliittymäkontrolli Windowskontrolli Motifkontrolli. kontrollit erilaisia eri ympäristöissä; kirjaston pitäisi olla yleinen, mutta miten voidaan yleisellä tasolla luoda ilmentymiä ympäristökohtaisille luokille? Harri Laine, Jukka Paakki 41 Ratkaisumalli Abstrakti tehdas (Abstract Factory) Client ConcreteFactory1 CreateProductA( ) CreateProductB( ) AbstractFactory CreateProductA (...) : abstract CreateProductB (...) : abstract ConcreteProductA1 ConcreteFactory2 CreateProductA( ) CreateProductB( ) creates ConcreteProductB1 AbstractProductA ConcreteProductA2 AbstractProductB creates ConcreteProductB2 Harri Laine, Jukka Paakki 42 7
Ratkaisumalli Abstrakti tehdas (Abstract Factory) Ratkaisumalli Abstrakti tehdas (Abstract Factory) Client (siis hyödyntävä ohjelma) tuntee abstraktin tehtaan ja abstraktit tuotteet ja kutsuu näiden tarjoamia palveluja. Abstraktin tehtaan palvelukutsu ohjautuu konkreettisen tehtaan vastaavaan luontipalveluun, joka siis luo ilmentymän kyseisen tyyppiselle tuotteelle Esim. Windows-kontrollitehtaan LuoNappi-palvelu luo ilmentymän winnappi-luokkaan. Client KontrolliTehdas LuoNappi (...) : abstract LuoLiuku (...) : abstract winnappi creates winliuku Nappi motifnappi Liuku motifliuku KontrolliTehdasWin LuoNappi( ) LuoLiuku( ) KontrolliTehdasMotif LuoNappi( ) LuoLiuku( ) Harri Laine, Jukka Paakki 43 Harri Laine, Jukka Paakki 44 Ratkaisumalli Abstrakti tehdas (Abstract Factory) Mallilla eristetään konkreettiset tehtaat asiakkaasta Tuoteperhe voidaan helposti vaihtaa toiseksi Asiakkaan on tunnettava tuotetyypit, joten uusia tuotetyyppejä ei voida lisätä pelkästään aliluokkia lisäämällä, vaan tällöin on muutettava asiakkaan koodia ja abstraktin tehtaan koodia esim. kilistimen lisäys käyttöliittymäkontrolleihin Komento (Command) -suunnittelumalli soveltuu tilanteisiin, joissa operaation käynnistämiseen on erilaisia vaihtoehtoja, mutta lopputuloksen pitäisi kuitenkin olla sama järjestelmään pitäisi pystyä helposti liittämään uusia operaatioita puuttumatta järjestelmän perusrakenteisiin operaatioita pitäisi pystyä perumaan ja uudelleensuorittamaan Suunnittelumallissa varsinainen toiminta eristetään toimintapyynnöstä muodostamalla pyynnöstä erillinen komento -olio Kaikilla komennoilla on yhteinen rajapinta, joka pitää sisällään vähintään palvelun suorita (do, execute) Harri Laine, Jukka Paakki 45 Harri Laine, Jukka Paakki 46 Komennon rajapintaan voi lisäksi kuulua peruutus (undo) toimiakseen peruutus saattaa edellyttää edeltäneen tilan kirjaamista komennon tietorakenteisiin esim. kun teksti korvataan toisella, on peruutusta varten taltioitava korvattu teksti sen alkukohta ja korvaavan tekstin pituus uudelleensuoritus (redo) edellyttää myös tilatietojen tallennusta Komentojen suorituksen ohjausta voidaan hallita erityisen komentokäsittelijän (command processor) avulla komentokäsittelijä ei ole aina välttämätön, mutta se on tarpeen esimerkiksi peruutusten yhteydessä komentokäsittelijä ottaa vastaan komentoja (addcommand) ja tallentaa ne tyypillisesti komentojonoksi done previous next To do add Harri Laine, Jukka Paakki 47 Harri Laine, Jukka Paakki 48 8
Peruskuvio 1: Kun aiheuttaja (client, controller) haluaa saada aikaan toiminnon, se luo komennon ja joko aktivoi luomansa komennon suorituksen tai luovuttaa sen komentokäsittelijälle aktivoitavaksi Peruskuvio 2: Aiheuttaja reagoi käyttäjän toimenpiteeseen aktivoimalla siihen ennalta kytketyn komennon suorituksen Client (esim. pääohjelma) luo konkreettisen komennon (esim. OpenFile). Se kytketään jotenkin aiheuttajaan Invoker (esim. MenuVaihtoehto - mainmenu. additem( Open, new OpenFile()) Harri Laine, Jukka Paakki 49 Harri Laine, Jukka Paakki 50 controller command processor receiver create addcommand (d) execute() d: delete command getselection() deletetext undo() undo() appendtext( stored, position) Harri Laine, Jukka Paakki 51 Harri Laine, Jukka Paakki 52 Yleensä on järkevää mahdollistaa myös komennot, jotka kootaan alkeellisemmista komennoista tällöin koottu komento (makro) on syytä toteuttaa koosteen (Composite) mukaisesti: command execute() * part Komentoja on suhteellisen helppo lisätä määritellään uusi komentoluokka Sama toiminto on kytkettävissä eri käynnistystapoihin Suuren komentomäärän välttämiseksi komentoja kannattaa yleistää ja parametroida macrocommand execute() for each part {part.execute() Harri Laine, Jukka Paakki 53 Harri Laine, Jukka Paakki 54 9
Ratkaisumalli Vierailija (Visitor) Vierailija (Visitor) soveltuu käytettäväksi kun erilaiset liittymät ja rakenteet omaaville kohteille halutaan suorittaa toimenpiteitä, jotka riippuvat konkreettisista luokista yhteenliittyvää operaatiokokonaisuutta ei haluta sirotella luokkiin eri käyttötilanteisiin liittyvän tilannekohtaisen koodin mukanaolo luokissa ei edistä uuskäyttöä rakenne on staattinen mutta operaatiot dynaamisia Ratkaisumalli Vierailija (Visitor) Ratkaisumallissa kootaan luokkakohtaiset palvelut vierailijan metodeiksi. Vierailijalla on kutakin luokkaa kohti oma erityismetodinsa. Oliot rekisteröivät vierailijan ja suorittavat palvelunsa kutsumalla vierailijan luokkakohtaista metodia. Vierailijan vaihtaminen vaihtaa palvelun. Vierailijan abstraktissa määrittelyssä on otettava huomioon kaikki konkreettiset luokat, joissa vierailija voi käydä => rakenne on ylläpidon kannata hankala. Harri Laine, Jukka Paakki 55 Harri Laine, Jukka Paakki 56 Ratkaisumalli Vierailija (Visitor) client ObjectStructure AbstractElement accept(visitor) visita() visitb() Visitor1 AbstractVisitor visita() visitb() Visitor2 visita() visitb() Ratkaisumalli Vierailija (Visitor) objectstructure elementa elementb visitor1 accept(visitor1) visita(elementa) operationa accept(visitor1) visitb(elementb) operationb v.visita(this); ElementA ElementB v.visitb(this); accept(visitor v) accept(visitor v) Harri Laine, Jukka Paakki 57 Harri Laine, Jukka Paakki 58 Ratkaisumalli Vierailija (Visitor) Toiminnallisia kokonaisuuksia saa lisättyä laatimalla uuden konkreettisen vierailijan Elementeissä voidaan aina varautua vierailijoihin Vierailija erottaa toiminnan ja tietorakenteen Tiukka kytkentä vierailijasta vierailtavaan. Vierailtavan muutos aiheuttaa yleensä aina muutoksen myös vierailijaan Epäsuora suoritusaikainen kytkentä käynnistyvään toimintaan normaalisti (C++, Java) olion luokka ja palvelun nimi määräävät toiminnon, ratkaisumallia käytettessä mukaan tulee lisäksi vierailija Suunnittelumallit (Gamma) Luonti Abstract Factory : samankaltaisten olioiden abstrakti luonti Factory Method: virtuaalinen luontioperaatio Builder : olion rakenteen eristäminen sen luonnista Prototype: kloonattavissa olevan prototyyppi-olion luonti Singleton: yhden ainokaisen luokkailmentymän luonti Harri Laine, Jukka Paakki 59 Harri Laine, Jukka Paakki 60 10
Suunnittelumallit (Gamma) Rakenne Adapter : luokan rajapinnan muuntaminen Bridge: abstraktin luokan ja konkreettisen luokan eristäminen toisistaan Composite: hierarkkisen rakenteen yhdenmukainen käsittely Decorator: olion toiminnallisuuden laajentaminen dynaamisesti Facade: yhtenäisen rajapinnan luominen erityyppisille luokille Suunnittelumallit (Gamma) Rakenne Flyweight: yleiskäyttöiset, jaetut oliot Proxy: olion edustaminen erillisellä valvojalla Harri Laine, Jukka Paakki 61 Harri Laine, Jukka Paakki 62 Suunnittelumallit (Gamma) Toiminta Chain of Responsibility: palvelupyynnön delegointi olioketjua pitkin Command: komento oliona Interpreter : kielen kielioppipohjainen tulkki Iterator: rakenteen osissa vierailu Mediator: olioiden välisen vahvan kytkennän muuttaminen löyhäksi Memento: olion tilan tallentaminen Suunnittelumallit (Gamma) Toiminta Observer : olion tilamuutosten valvonta State: olion toiminnallisuuden muuttaminen tilamuutoksen yhteydessä Strategy: algoritmiperheen toteutus Template Method: algoritmin luuranko Visitor: rakenteen osien käsittely järjestyksessä Harri Laine, Jukka Paakki 63 Harri Laine, Jukka Paakki 64 4. Arkkitehtuurimallit 4. Arkkitehtuurimallit Tasot (Layers ) F. Buschmann et al.: Pattern-Oriented Software Architecture A System of Patterns. John Wiley, 1996 arkkitehtuuritason ratkaisumalleja myös suunnittelumalleja ja idiomeja kuvaustapa vähemmän systemaattinen kuin Gamman kirjassa mallit eivät välttämättä olioperustaisia Client Layer N Layer N-1 Layer 1 Harri Laine, Jukka Paakki 65 Harri Laine, Jukka Paakki 66 11
Etsintä 5. Arkkitehtuurin mittaaminen Maisa Arkkitehtuurin mittaaminen Maisa CallPartsFactory CreateSignaling() CreateSubscriber() TerminalPartsFactory TrunkPartsFactory CreateSignaling() CreateSignaling() CreateSubscriber() CreateSubscriber() <<create>> Charging Start() TrunkSignaling Stop() Phase1() Status Phase2() SS7-ISUP Call A-Subscriber B-Subscriber Start() HangUp() <<>> Signaling Status LocalSubscriber DialNumber() Answer() Data Terminate() TerminalSignaling TerminalSignaling Status ISDN-BRI Q.931 Hyvä vai huono? Subscriber Data Signaling ExternSubscriber Data TrunkSignaling Maisa : Laitoksen tutkimusprojekti (Metrics for Analysis and Improvement of Software Architectures) Hypoteesi : (anti-)suunnittelumallit ilmentävät arkkitehtuurin laatua Hypoteesi : arkkitehtoniset mallit ennustavat ohjelmiston laatua Malleja voi löytää arkkitehtuurista automaattisesti Arkkitehtuuria voi mitata (lisäksi perinteisin ohjelmistomittarein) <<create>> Harri Laine, Jukka Paakki 67 Harri Laine, Jukka Paakki 68 Ulkoinen reverse engineering -työkalu Ohjelmakoodi Arkkitehtoninen löydös Abstract Factory Ohjelmisto - arkkitehtuuri Mallikirjasto Sisäinen esitysmuoto Ulkoinen CASE-työkalu Maisa Mittaus- ja etsintä - konfiguraatio Mittaus- ja etsintä - tulokset, ennusteet Visualisointi CallPartsFactory CreateSignaling() CreateSubscriber() TerminalPartsFactory TrunkPartsFactory CreateSignaling() CreateSignaling() CreateSubscriber() CreateSubscriber() <<create> > Charging Start() TrunkSignaling Stop() Phase1() Status Phase2() SS7-ISUP <<create>> Call A-Subscriber B-Subscriber Start() HangUp() <<>> Subscriber Data Signaling Signaling Status LocalSubscriber ExternSubscriber DialNumber() Answer() Data Data Terminate() TerminalSignaling TrunkSignaling TerminalSignaling Status ISDN-BRI Q.931 Harri Laine, Jukka Paakki 69 Harri Laine, Jukka Paakki 70 Maisa - Perinteisiä suunnittelumittareita Koko : 11 luokkaa, 8 attribuuttia, 13 operaatiota Mutkikkuus : syvyys 2, leveys 2, kytkentä 4, McCabe 5 Suoritusaika : best-case 500, worst-case 1000, average-case 725 Lasketaan UML:n luokka-, tila-, aktiviteetti- ja sekvenssikaavioista Malliesiintymät toistaiseksi vain luokkakaavioista Harri Laine, Jukka Paakki 71 12