Ohjelmistoarkkitehtuurit Kevät 2014

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät 2014 Samuel Lahtinen (Johannes Koskinen)

2 5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Esimerkki: Rekursiokooste Antisuunnittelumallit Suunnittelumallit ja UML Mallikielet Suunnittelumallit eivät ole... Yhteenveto

3 Suunnittelumallin käsite: tausta Cristopher Alexander et al.: A Pattern Language, 1977 Cristopher Alexander: The Timeless Way of Building, 1979 Maailma koostuu toistuvista tiettyjen mallien ilmentymistä Esimerkki: Jokainen maanviljelijä osaa rakentaa ladon - miksi? Malli (pattern) on yleistä suunnitteluosaamista, joka olisi saatettava kaikkien tarvitsijoiden ulottuville Alexander: mallien käyttö johtaa hyvään laatuun Paljon käytetty eri muodoissa insinöörialoilla Erityisen hyödyllinen ajatus ohjelmistotekniikassa

4 Esimerkki: Ikkunat ja ovet hirsitalossa hirret painuvat kasaan Ongelma: ikkunat ja ovet ovat kiinteitä, vaikka hirsiseinä liikkuu ja painuu kasaan. Ratkaisu: ikkunoiden ja ovien karmeja ei kiinnitetä suoraan seinään, vaan "karaan", joka liikkuu vapaasti hirsiin tehdyssä urassa

5 Tukikaari (Flying buttress)

6 Mikä on suunnittelumalli? Suunnittelumalli Yleinen ratkaisu usein esiintyvään ohjelmistojen arkkitehtuuri- tai suunnitteluongelmaan tietyssä yhteydessä

7 Selitystä Yleinen ratkaisu... ei liity tiettyyn kieleen tai teknologiaan, kuvataan yleisellä tavalla... usein esiintyvään... täytyy olla käytännön validoima (esim. GoF: 3 esimerkkiä)... arkkitehtuuri- tai suunnitteluongelmaan... sovelletaan ohjelmistotekniikassa arkkitehtuurin ja yksityiskohtaisen suunnittelun tasolla... tietyssä yhteydessä. ongelma esiintyy yhteydessä, josta seuraa erilaisia vaatimuksia ja voimia

8 Suunnittelumallien hyötyjä Suunnittelumallit... tuovat piilossa olevaa suunnittelutietämystä kaikkien saataville; auttavat järjestelmän dokumentoinnissa; antavat uuden korkeamman tason toteutusvälineen; toimivat arkkitehtuurin rakennuspalikoina; antavat suunnittelijoille yhteisen sanaston

9 Suunnittelumallin kuvaus Keskeiset osat: Nimi Konteksti Ongelma Ratkaisu Seuraukset Kuvaava ytimekäs nimi, tulee osaksi yhteistä sanastoa Lähtötilanne Ongelman ja siihen vaikuttavien tekijöiden kuvaus, oletukset, esimerkki Luokkien ja olioiden organisointi ongelman ratkaisemiseksi (esim. käyttäen UML:ää) Lopputilanne, ratkaisun edut ja haitat

10 GoF:in kuvausformaatti "Gang of Four kirja, GoF: Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Name (and category) Intent Also known as Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample code Known uses Related patterns

11 Esimerkki suunnittelumallista: Rekursiokooste Ongelma: Olioita käyttävä komponentti tee joku operaatio lehtiolioille

12 Rekursiokooste (Composite) suunnittelumalli Nimi: Rekursiokooste Konteksti: Hierarkkinen oliokokoelma, jonka (lehti)olioille halutaan tehdä jokin operaatio. Ongelma: Kuinka hallita hierarkkisesti järjestettyä oliokokoelmaa niin, että kokoelman käyttäjän ei tarvitse tuntea rakenteen organisointitapaa? Ratkaisu: Käyttäjä Item operation() * children Leaf operation() Composite operation() For all children c: c.operation()

13 Rekursiokooste (jatkuu) Seuraukset: Hierarkiarakenne ei näy käyttäjän koodissa Käyttäjän koodi yksinkertaistuu Rakenteeseen on helppo lisätä uusia kooste- ja lehtiluokkia (ei näy käyttäjälle) Pieni tehokkuusrasite kutsun siirtämisen takia (ei mahdollista rajoittaa lehtiluokkien tyyppiä tietyssä haarassa/vaiheessa)

14 Esimerkki soveltamisesta SourceManager <<interface>> Source delete() print() * children File delete() print() Folder delete() print() add(source) For all children c: c.delete(); Delete folder

15 Kysyttävää?

16 Antisuunnittelumallit Ongelma Suunnittelumalli Hyvä ratkaisu Seuraukset Antisuunnittelumalli Huono ratkaisu Oireet Muokkaus Antisuunnittelumalli = huono ratkaisu + hyvä ratkaisu Suunnittelumalli = ongelma + ratkaisu Brown W.J. et al.: Antipatterns - Refactoring Software, Architectures, and Projects in Crisis. Wiley

17 Dokumentoituja antisuunnittelumalleja The Blob Lava flow Golden Hammer Spaghetti Code Cut-and-Paste Programming

18 Antisuunnittelumallien oireita Huono ylläpidettävyys Huono uudelleenkäytettävyys Huono laajennettavuus Vaikeasti ymmärrettävä Tehottomuus

19 Mitä huonoja ratkaisutapoja olet tunnistanut oliojärjestelmissä?

20 Suunnittelumallit ja UML: Kollaboraatiosymboli Item Composite SourceManager Source delete() print() Leaf * children Composite File delete() print() Folder delete() print() add(source) For all children c: c.delete(); Delete folder

21 Esimerkki EventSource register(statemachine) * * informs StateMachine run(state) handle(event) 1 Singleton State Observer 1 Event source(): Object current.exit(); current = current.transit(e); current.entry(); uses 0..1 current State transit(event): State entry() exit() Event1 source(): Object Event2 source(): Object StateA transit(event): State entry() exit() StateB transit(event): State entry() exit()

22 Suunnittelumallit ja UML: Stereotyypit SourceManager <<Composite_Item>> Source delete() print() * children <<Composite_Leaf>> File delete() print() <<Composite_Composite>> Folder delete() print() add(source) For all children c: c.delete(); Delete folder

23 Suunnittelumallit eivät ole Eivät ole vain GOF-patternit, vaan paljon muutakin. Ei vain yksinkertaisia muutaman olion vuorovaikutusrakenteita yleinen lääke ohjelmiston laadun parantamiseen; ongelmattomia: arkkitehtuurin monimutkaistuminen mahdollinen ongelman yliratkaisu tehokkuushäviö: runsaasti dynaamista sidontaa ja kutsun siirtämistä olion identiteetti hämärtyy: olioskitsofrenia tarvitsevat hyvän dokumentoinnin järjestelmässä Perinteiset (GOF) suunnittelumallit usein toteuttajan ja alijärjestelmän suunnittelijan työkaluja Anti-Arkkitehtuuridokumentaatio: ylimalkainen kertomus järjestelmän toiminnasta ja iso lista suunnittelumalleja, joilla luvataan järjestelmän täyttävän kaikki mieleen tulevat laatuominaisuudet

24 Yhteenvetoa Suunnittelumallit antavat hyväksi havaittuja ratkaisuja yleisiin suunnitteluongelmiin Käytä suunnittelumallia vasta kun ongelma on selvästi ymmärretty Suunnittelumallit ovat kokemusperäistä tietoa, eivät innovaatioita Antisuunnittelumallit auttavat tunnistamaan ongelmakohtia

25 Kysyttävää?

26 Komponenttien vuorovaikutus Roolirajapinnat Välittäjät Fasaadit Kutsun siirtäminen Edustajat Takaisinkutsut Tapahtumat Viestit Sovittimet Tehtaat 26

27 Toteutusriippuvuuksien poistaminen rajapinnoilla A B A IB mitä A ei tunne B miten 27

28 Rooliperustaiset rajapinnat Client1 Services Server Client1 käyttää Server:iä eri roolissa ja siksi eri palveluja kuin Client2 Client2 Client1 Role1 Server Client2 Role2 28

29 Esimerkki VisualComponent Button EventSource 29

30 Hienojakoiset roolirajapinnat Asiakkaat X Y Z Roolit A B C D Palvelun tarjoajat P:n perinteinen rajapinta P Q Q:n perinteinen rajapinta 30

31 Komponenttien vuorovaikutuksen hallinta Joukko keskenään kommunikoivia komponentteja Ongelmia: komponenttien väliset riippuvuudet mutkikkaita ja vaikeita hallita jos jokin yhteistoiminta halutaan muuttaa, joudutaan jokaista osallistujaa muuttamaan komponentteja ei voi käyttää toisessa yhteydessä 31

32 Esimerkki ListBox TextField Button 32

33 Esimerkki Ilmanlaadun hallinta avaa ikkuna Ikkunoiden hallinta sulje ilmastointi Ilmastoinnin hallinta 33

34 Riippuvuuksien keskittäminen: Välittäjä (Mediator) Keskitetään vuorovaikutuksen kontrolli rajoittamalla komponenttien vastuut ja ottamalla käyttöön uusi komponentti, jonka vastuulla on vuorovaikutuksen hallinta Etuja: vuorovaikutus omana kokonaisuutena (välittäjä), voidaan muuttaa tai räätälöidä koskematta komponentteihin tekee komponentit riippumattomiksi toisistaan yksinkertaistaa kommunikaatiota (yksi-moneen, ei moni-moneen) Ongelma: keskitetty kontrolli voi kasvaa itsessään monimutkaiseksi 34

35 Esimerkki Coordinator widgetchange(widget) ListBox ListBoxI getselected(): str Dialog Coordinator Välittäjä TextField TextFieldI settext(str) Widget changed() Button ButtonI enable() 35

36 Tyypillinen vuorovaikutus ListBox DialogCoordinator TextField Button widgetchange getselected settext enable 36

37 Esimerkki Ilmanlaadun hallinta avaa ikkuna sulje ilmastointi Ikkunoiden hallinta Ilmastoinnin hallinta 37

38 Kysyttävää? 38

39 Kutsun siirtäminen (delegointi) Yleinen perusmekanismi monessa standardiratkaisussa B saa palvelupyynnön: palvelun varsinainen suorittaja Bimp opimp() imp op op() B op op() B Voi olla erilaisia syitä: - halutaan tehdä oheistoimintaa, joka ei näy palvelun pyytäjälle - halutaan pystyä helposti vaihtamaan toteutus dynaamisesti - halutaan muuttaa kutsumuotoa - halutaan piilottaa varsinainen suorittaja imp.opimp(); 39

40 Kutsun siirtäminen: esimerkki Chargable discount(int): int CustomerSupport discount(int): int Account Manager Customer KeyCustomer Support 40

41 Riippuvuuksien kuristaminen: Fasadi (Facade) Fasaadi alijärjestelmä alijärjestelmä 41

42 Fasadi (kulissi/julkisivu) suunnittelumalli Käytetään antamaan yksinkertainen, useimmille käyttäjille riittävä oletusliittymä monimutkaiseen alijärjestelmään Fasadi ei kuitenkaan täysin piilota alijärjestelmän komponentteja suoralta käytöltä Voidaan käyttää esimerkiksi kerrosarkkitehtuurissa antamaan kullekin kerrokselle yksinkertainen sisääntulokohta (ja rajapinta) Vrt. Välittäjä: yksisuuntainen palvelu, tyypillisesti fasaadi vain siirtää kutsun oikealle komponentille (tai mahdollisesti useille komponenteille) Fasadin käyttöä voidaan edelleen kaventaa roolirajapinnoilla 42

43 Esimerkki StudyRegister registerforsemester getstudentinfo StudentFacade StudentRegister regstudentforcourse unregstudentforcourse PaymentSystem 43

44 Komponenttiriippuvuuksien poistaminen edustajalla (Proxy) Edustaja: komponentti, joka edustaa toista komponenttia jossain yhteydessä ilman, että komponentin asiakkaat tietävät tätä. Tyypillisesti edustaja tekee palvelupyynnön yhteydessä jotain oheistoimintaa. Asiakas op op Palvelun Edustaja tarjoaja 44

45 Sovelluksia hajautetut järjestelmät (esim. EJB) viivästetty lataaminen (esim. oliokannat) älykkäät osoittimet... 45

46 Edustaja (Proxy) suunnittelumalli Client Services request()... actual.request() Proxy request() actual Server 46

47 Esimerkki: viivästetty lataaminen Navigator Map getname() getroute(from,to) varsinainen getroute palvelu return mapname; MapProxy CityMap if not loaded then map = loadfromfile(); loaded = true end; map->getroute() getname getroute getname getroute 47

48 Kysyttävää? 48

49 Riippuvuuksien poistaminen takaisinkutsuilla Takaisinkutsu Palvelun tarjoajalta sen pyytäjälle kesken palvelun tuleva kutsu. Tekniikka, jonka avulla palvelun pyytäjä voi saada kontrollin kesken palvelun suorituksen. Tavallisesti palvelu kuuluu johonkin yleiskäyttöiseen kirjastoon, joka ei saa tulla riippuvaksi kirjastoa käyttävistä sovelluksista. Takaisinkutsu mahdollistaa sovelluskohtaisen räätälöinnin yleiskäyttöisille palveluille ilman, että ne tulevat riippuviksi sovelluksista. 49

50 Takaisinkutsu (Callback) kirjasto sekvenssikaaviona: : Kirjasto : Sovellus palvelun kutsu palvelun kutsu paluu takaisinkutsu takaisinkutsu paluu palvelun paluu sovellus takaisinkutsu 50

51 Takaisinkutsurajapinta EngineUser warn(str) Takaisinkutsurajapinta run() Engine Yleiskäyttöinen if (oilpressure<limit) { user.warn();... myeng = new Engine(); myeng.setuser(this); myeng.start(); PowerSource start() stop() setuser(engineuser) Car setup() warn(str)... Sovelluskohtainen log.output("oil pressure low"); myeng.stop(); 51

52 Käytetään poikkeuksia? Voidaanko poikkeuksilla saada periaatteessa aikaan sama kuin takaisinkutsuilla? A Ei koskaan B Joskus C Aina 52

53 Poikkeuksilla Engine run() if (oilpressure<limit) {... throw new Oilpressure(); }... PowerSource start() throws Oilpressure stop() setuser(engineuser) setup():... myeng = new Engine(); myeng.setuser(this); try { myeng.start(); } catch (Oilpressure op) {warn("...");} Erot: Edut: Haitat: - ei takaisinkutsurajapintaa - käyttävän yksikön (Car) tulee varautua poikkeukseen - yksinkertaisempi - kirjastoyksikön ei tarvitse tietää mitään käyttävän yksikön operaatioista (edes takaisinkutsurajapintaa) - kirjastoyksikkö ei voi jatkaa tapahtuman käsittelyn jälkeen (tässä tosin ei ilmeisesti tarvitsekaan) -ohjelman suorituksen seuraus, poikkeusten mahdollinen väärinkäyttö normaalitilanteissakin(goto) Yleiskäyttöinen Car setup() warn(str)... Sovelluskohtainen log.output(str+": Oil pressure low"); myeng.stop(); 53

54 Kysyttävää? 54

55 Riippuvuuksien vähentäminen tapahtumien avulla Tapahtuma on ohjelman ajoaikainen tietoalkio, jonka synnyttää jokin komponentti, jonka syntymiseen reagoi yksi tai useampi komponentti ja joka häviää sen jälkeen kun ei ole olemassa enää komponenttia, jonka tulisi reagoida sen syntymiseen. Tapahtuman synnyttäjä ei tunne tapahtuman syntymään reagoivia yksiköitä 55

56 Perinteinen kutsu vs. tapahtuma Palvelun kutsuja Tapahtuman synnyttäjä Palvelun tarjoaja Tapahtuma Tapahtumaan reagoivat 56

57 Tapahtumat käyttöliittymissä GUI Käyttäjän komennot Tilamuutokset Sovelluslogiikka 57

58 Synkroninen takaisinkutsuihin perustuva tapahtumankäsittely rekisteröinti Synkroninen = tapahtuman aiheuttaja odottaa tapahtuman käsittelyä ennen kuin jatkaa. Reagoivat yksiköt Tapahtuman aiheuttaja ilmoitus tapahtumasta (takaisinkutsu) 58

59 Tarkkailija (Observer) suunnittelumalli Observer update(event) SourceComp obs src ObserverComp Source register(observer) unregister(observer) 59

60 Tapahtumien käsittely Javassa: Esimerkki ActionListener actionperformed(actionevent) JMenuItem obs src AppComp AbstractButton addactionlistener(actionlistener) 60

61 Viestipohjainen kommunikointi receive(message m) Viesti Komponentti 1 Komponentti 2 Komponentit toteuttavat geneerisen viestin vastaanottorajapinnan (ja käyttävät sitä suoraan tai viestinvälittäjän kautta) Komponentit kommunikoivat keskenään viestejä lähettämällä Viestien välittämisestä huolehtii usein erityinen komponentti (message dispatcher) 61

62 Rajapinnat vs. viestit Komponentit, Asiakas-palvelin, Web palvelut (SOA), C++, Java func A(X ) Rajapinta toteuttaa Palvelun tarjoaja Palvelun pyytäjä Viestinvälitysarkkitehtuurit, palveluväylät (ESB), Smalltalk Viesti ACTION = A PAR1 = X Viestin välittäjä lukee ja toteuttaa Palvelun tarjoaja Rajapinta kertoo mitä tehdään ja millä tiedolla, viesti voi kertoa mitä tahansa (mitä tehdään, kuka tekee, millä tiedolla). 62

63 Rajapintariippuvuuksien poistaminen sovittimilla Rajapinnan A mukainen palvelupyyntö Sovitin Rajapinnan B mukainen Komponentti 1 palvelupyyntö Komponentti 2 Sovitin: palvelun pyytäjän ja tarjoajan välillä oleva ohjelmayksikkö, joka tekee palvelun pyytäjän riippumattomaksi palvelun tarjoajan rajapinnasta. 63

64 Sovitin (Adapter) suunnittelumalli Client AbstractServices request() ConcreteServices concrequest()... adaptee.concrequest() Adapter request() adaptee Server 64

65 Sovitin ja tapahtumat Sovittimien käyttö riippumattomien komponenttien tapahtumapohjaisessa kommunikoinnissa rekisteröinti ilmoita tapahtumasta palvelukutsu Komponentti A Sovitin Komponentti B Ohjelmistoarkkitehtuurit

66 Luontiriippuvuuksien vähentäminen tehtaalla Ongelma: Miten ohjelmistoalusta tai yleiskäyttöiset komponentit voivat luoda sovelluskohtaisia olioita/komponenttiilmentymiä tulematta riippuvaisiksi sovelluskohtaisista luokista/komponenteista? Ohjelmistoarkkitehtuurit

67 Luontiriippuvuuksien vähentäminen tehtaalla FactoryRegistry register(factory) AppInit Factory create(): Product AppFactory <<create>> (alustus) Platform <<create>> (käyttö) Product service AppProduct Ohjelmistoarkkitehtuurit

68 Yksinkertainen tehdas: Tehdasmetodi (Factory Method) suunnittelumalli Product Creator factorymethod anoperation product = factorymethod();... AppProduct create ConcCreator factorymethod return new AppProduct(); Ohjelmistoarkkitehtuurit

69 Esimerkki Document open() close() use DocManager createdocument() newdocument() opendocument() doc = createdocument(); docs.add(doc); doc.open(); MyDocument open() close() create MyDocManager createdocument() return new MyDocument; Ohjelmistoarkkitehtuurit

70 Ongelma: Miten varmistaa yhdenmukaiset oliot? Alusta TAI MUTTA EI: Ohjelmistoarkkitehtuurit

71 Ratkaisu: yksi tehdasolio luo kaikki oliot yhdenmukaisesti ShapeFac tehdasluokka TwoDimFac ilmentymä tehdasolio käyttää Alusta luo ilmentymä ThreeDimFac factory class Ohjelmistoarkkitehtuurit

72 Abstrakti tehdas suunnittelumalli AbsFactory createproducta(): ProductA createproductb(): ProductB ProductA2 opera ProductA opera ProductA1 opera Alusta ProductB operb ProductB2 ProductB1 operb operb Factory1 <<create>> Factory2 <<create>> Ohjelmistoarkkitehtuurit

73 Abstrakti tehdas (Abstract Factory) suunnittelumalli: Esimerkki Sovellusalusta AbsFactory createbutton(): Button createmenu(): Menu WinFactory Button Menu <<create>> WinButton WinMenu Ohjelmistoarkkitehtuurit

74 Yhteenvetoa Roolirajapinnoilla täsmällisemmin tyypitetty arkkitehtuuri Välittäjän käyttö keskitettyyn vuorovaikutukseen Kutsun siirtäminen perusmekanismi monessa ratkaisussa Fasaadi keskittää alijärjestelmän käytön Edustajalla voidaan liittää palveluun oheistoimintaa Takaisinkutsulla kontrolli palautetaan väliaikaisesti kutsujalle Tarkkailija yleinen ratkaisu tapahtumapohjaiseen vuorovaikutukseen Viestipohjainen kommunikointi löyhentää sidoksia Tapahtumapohjaisuus (ja viestipohjaisuus): väärin käytettynä tekee ohjelman rakenteesta ja suorituksen seuraamisesta haastavaa vastuualueet sekaisin, päivittäminen vaatii meedion kykyjä kun asiat pilkottu sekaviksi pikkupätkiksi sinne tänne Ohjelmistoarkkitehtuurit

75 Kysyttävää? Ohjelmistoarkkitehtuurit

76 Periytymisen toteutus kutsun siirtämisellä täydellinen" Car olio printdescription-kutsu self Car parent Vehicle parent Commodity parent printdescription: {printname;... } 76

77 Periytymisen toteutus kutsun siirtämisellä Täydellinen" Car olio printdescription-kutsu self Car parent Vehicle parent Product parent Commodity parent printdescription: {printname;... } 77