Ohjelmoinnin peruskurssien laaja oppimäärä Luento 7: UML, suunnittelumalleja Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 25. 2. 2012
Sisältö 1 Lisää ohjelmien suunnittelusta 2 UML-luokkakaaviot 3 Suunittelumallit 4 Suunnittelumallit Factory Method ja Abstract Factory 5 Suunnittelumallit Decorator ja Proxy
(ei-laajan kurssin kalvo: luento 2 sivu 11) Suunnittelu Turhien riippuvuuksien välttäminen kannattaa myös alemmilla tasoilla Toisaalta samasta tiedosta ei yleensä kannata pitää useita kopioita Yhtä päivitettäessä pitää aina päivittää muutkin Myös riippuvasta datasta olevat kopiot voivat olla ongelmallisia Tällöin riippuvan datan turha uudelleenlaskeminen voi olla hyödyllistä. 11:31
(ei-laajan kurssin kalvo: luento 2 sivu 12) Suunnittelu Mistä tiedetään, mitä luokkia pitäisi laatia tietyn ongelman ratkaisemiseksi? Millaisia kenttiä ja metodeja niille tulee? Ei ole yhtä parasta ratkaisua. Suunnittelutavoitteet voivat olla ristiriitaisia tasapainottelu, kompromissit. Ei ole menetelmää, jolla päästään varmasti hyvään tulokseen. Ei ole yleispätevää tapaa selvittää, onko jokin ratkaisu hyvä tai huono. Useimmille nyrkkisäännöille löytyy tapauksia, joissa kannattaakin toimia toisin. 11:31
(ei-laajan kurssin kalvo: luento 2 sivu 13) Substantiivimenetelmä Yksi kirjallisuudessa esitelty tekniikka tehdä ensimmäinen malli ohjelman luokkarakenteesta 1)Kirjoitetaan lyhyehkö mutta tarkka sanallinen kuvaus ohjelman toimintavaatimuksista 2)Etsitään kuvauksesta kaikki verbit ja substantiivit 3)päätetään mitkä substantiiveista ovat luokkia, mitä näiden luokkien kenttiä 4)päätetään mitkä verbeistä ovat luokkien metodeja Vain alustava malli Kun ensimmäinen malli on saatu pohdittua niin sitä ryhdytään muokkaamaan ja tarkistetaan voidaanko sen avulla todella toteuttaa vaatimukset. 11:31
(ei-laajan kurssin kalvo: luento 2 sivu 17) Käyttötapaukset (use case) ja mallin kehittäminen Kun alustava malli on rakennettu, kokeile sitä jo ennen koodausta erilaisilla käyttötavoilla Esim. Kuinka ja mitä metodeja kutsuttaisiin jos käyttäjä siirtää rahaa tililtä toiselle? Miten metodit tilisiirrossa kutsuvat toisiaan? Millaisia parametreja pitäisi laittaa? Löytyykö luokista tarvittavaa dataa. Muokkaa ja tarkenna mallia käymällä läpi joukko erilaisia käyttötapauksia. Kun olet tyytyväinen alustavaan malliin voit aloittaa koodailun. Malli tulee varmasti muuttumaan vielä koodausvaiheessa 11:31
Lisää ideoita suunnitteluun joskus suunniteltava ohjelma kannattaa jakaa osiin useampi ohjelma tai (yleiskäyttöisiä) kirjastoja + ohjelma joskus näitä osia voi yhdistää monella tavalla usein niitä voi käyttää yksinään (ei välttämättä kätevästi) hyödyllinen ajattelutapa: rajapinta voi olla kieli oikea pieni kieli, jota esim. tulkataan tai kokoelma funktioita, jotka on nimetty niin että niitä käyttävä koodi muistuttaa kieltä (esim. SICPin picture language-esimerkki) tai niin yleiskäyttöisiä funktioita, että niitä voi käyttää yhtä monipuolisesti kuin kieltä (esim. listankäsittelyfunktiot?) joskus kannattaa yleistää jos rajapinta vaikuttaa monimutkaiselta, voi olla parempi jakaa se geneerisempiin osiin mutta liika abstrahointi johtaa vaikeasti lähestyttävään koodiin
Pohdintaa ohjelman suunnittelu on eniten luovuutta ja kekseliäisyyttä vaativa osa ohjelmoinnissa ellei sitten sen suunnittelu, mitä ohjelman pitäisi tehdä... melkein kaikkia sääntöjä kannattaa joskus rikkoa suunnittelu on osin taidetta (kuinka paljon?) onkohan ohjelmoinnissa tyylisuuntia kuten taidehistoriassa? (esim. olio-ohjelmointi?) usein taiteen tyylisuunnista yksi kerrallaan on hallitseva ja seuraava tyylisuunta on jossain asioissa edeltäjäänsä parempi mutta toisissa taas huonompi joskus suunnittelun taustalla on pyrkimys löytää oikea tapa tehdä jokin tietty asia, The Right Thing esim. SICPin symbolinen derivoija taisi syntyä 60-luvulla näin suunnittelua oppii harjoittelemalla, mutta myös lukemalla muiden tekemiä ohjelmia
Sisältö 1 Lisää ohjelmien suunnittelusta 2 UML-luokkakaaviot 3 Suunittelumallit 4 Suunnittelumallit Factory Method ja Abstract Factory 5 Suunnittelumallit Decorator ja Proxy
(ei-laajan kurssin kalvo: luento 9 sivu 3) UML-mallinnuskieli UML UML-kieli luotiin 90-luvun puolivälissä korvaamaan joukko erilaisia mallinnuskieliä, joilla oli paljon yhteistä mutta myös paljon pikku eroja. Mallinnuskielen avulla on helppo suunnitella suurempia järjestelmiä, esittää tietoa nopeasti ja pienessä tilassa, selittää asioita muillekin kuin ohjelmoijille jne. jne. Parhaan kuvan mallinnuskielestä saa kokeilemalla sitä itse joten pitemmittä puheitta... Tutustutaan luokkakaavioon 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 4) UML luokkakaavio class Nelio(object): Nelio def init (self, yl,... self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol def laske_pinta_ala(self):... def aseta_vari(self, c):... 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 5) UML luokkakaavio class Nelio(object): Nelio +laske_pinta_ala() : int +aseta_vari(c: väri): def init (self, yl,... self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol def laske_pinta_ala(self):... def aseta_vari(self, c):... 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 6) -yla_laita -ala_laita -vasen_laita -oikea_laita UML luokkakaavio class Nelio(object): Nelio :Viiva :Viiva :Viiva :Viiva def init (self, yl,... self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol def laske_pinta_ala(self):... +laske_pinta_ala() : int +aseta_vari(c:väri): def aseta_vari(self, c):... 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 7) UML luokkadiagrammi class Nelio(object): -ylalaita -alalaita -vasenlaita -oikealaita Nelio :Viiva :Viiva :Viiva :Viiva def init (self, yl,... _self.yla_laita = yl _self.ala_laita = al _self.vasen_laita = vl _self.oikea_laita = ol def laske_pinta_ala(self):... +laske_pinta_ala() : int +aseta_vari(c:väri):void näkyvyysmääreet + public - private # protected default def aseta_vari(self, c):... muuttujan, parametrin tai paluuarvon tyyppi kaksoispisteen jälkeen 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 8) Suunnittelusta UML-luokkakaaviot Suunittelumallit Factory Decorator, Proxy Yhteyssuhde (assosiation) Nelio Viiva class Nelio(object): Suhteen suunta def init (self,yl, al, vl, ol): self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 9) Yhteyssuhde Nelio 1..2 4 Viiva class Nelio(object): def init (self,yl, al, vl, ol): self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol Multiplicity (kerrannaisuus) Kertoo kuinka moneen toisen luokan olioon jokin luokan olio on yhteydessä 3 tarkalleen kolme kpl 0..5 nollasta viiteen kpl 2..* vähintään kaksi kpl * Vapaavalintainen määrä Esimerkissämme yhteen neliöön kuuluu aina tasan 4 viivaa, mutta yksi viiva voi kuulua joko yhteen tai kahteen neliöön 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 10) Yhteyssuhde Nelio reunat 4 Viiva class Nelio(object): Rooli Karkeasti: kertoo mikä tämän suhteen pään merkitys on toiselle def init (self,yl, al, vl, ol): self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol päälle Viivan merkitys neliölle on, että se toimii neliön reunana. 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 11) Suhteen suunta Nelio reunat 4 Viiva Viivan kentissä ei välttämättä ole viittauksia Neliö-luokan olioihin Neliön kentissä on jollain tavalla tallessa viittauksia Viiva-olioihin class Nelio(object): def init (self,yl, al, vl, ol): self.yla_laita = yl self.ala_laita = al self.vasen_laita = vl self.oikea_laita = ol 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 12) Vahva ja löyhä kooste kuvaavat, että jokin koostuu pienemmistä osasista. Jos pääolioon kohdistetaan operaatioita, ne kohdistuvat jollain tavoin myös sen osasiin. Vahva kooste on jyrkempi kuin löyhä. Vahva kooste (composition) Nelio reunat 4 Viiva Neliö koostuu viivoista, jos neliö poistetaan viivatkin häviävät Löyhä kooste (aggregation) Pari 2 Yksilo Pari koostuu yksilöistä, jos pari purkautuu, yksilöt säilyvät silti 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 13) Riippuvuus Nelio reunat 4 Viiva +laske_pinta_ala() : int +aseta_vari(c:väri): Riippuvuus Karkeasti: Luokka käyttää toisen luokan olioita tai niiden metodeja (esim. parametreina) mutta ei säilytä viittauksia sen olioihin Väri 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 14) Perintä Kuvio Perintä Luokka perii toisen luokan ominaisuudet, ja sen olioon voidaan viitata yläluokan tyyppisen muuttujan kautta. Nelio reunat 4 Viiva 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 15) Esimerkki 2 vanhemmat Ihminen lapset * Rekursiivinen assosiaatio Luokan oliot voivat tietenkin viitata toisiin samanluokan olioihin. Esim Ihminen-luokassa voi olla viittaus muihin Ihminen-luokan olioihin. 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 16) Esimerkki Pankki Monta assosiaatiota Kahden luokan olioiden välillä saa olla myös useampia assosiaatioita, mutta tällöin kannattaa selittää mitä eri suhteet kuvaavat. 1 * Asiakas 1 omistaja * Pankkitili * * käyttöoikeus 14:43
(ei-laajan kurssin kalvo: luento 9 sivu 17) Abstrakti luokka <<abstract>> Työntekijä Abstrakti luokka Abstrakti luokka on luokka, joka toteuttaa joitakin metodeja, mutta osan metodeista kohdalla se ainoastaan toteaa että ne täytyy jonkun muun luokan toteuttaa. Abstrakti luokka on puolivalmis luokka, joka antaa vapaat kädet puuttuvien metodien toteutukselle. Kokki Poliisi 14:43
Miten UML:ää käytetään? UML:ää voi tuottaa automaattisesti koodista esim. työkaluilla Doxygen, Epydoc ja Pyreverse ja koodia voi autogeneroida (ohjelmilla tehdyistä) luokkakaavioista sisäänrakennettuna joihinkin IDEihin, erikseen esim. dia2code mutta usein käsin tehty luokkakaavio on hyödyllisempi: luokkakaavion abstraktiotaso kannattaa valita sen mukaan, mitä sillä haluaa kertoa (ei kaikkia kenttiä ja metodeja) kaaviossa voi esim. keskittyä tietyn toiminnon kuvaamiseen tai ulkoisen rajapinnan kuvaamiseen luokkakaavio on suunniteltu staattiseen olio-ohjelmointiin erityisesti Java- ja C++-koodiin (mm. näkyvyydet ovat niistä) Pythonin dynaamisia ominaisuuksia ei aina voi kuvata kunnolla UML määrittelee muitakin kaaviotyyppejä kuin luokkakaavion mm. kuvaamaan metodikutsujen etenemistä tietyssä käyttötapauksessa (sequence diagram)
UML-esimerkki gedit-2.30.4/docs/class-diagram.dia (osa)
Sisältö 1 Lisää ohjelmien suunnittelusta 2 UML-luokkakaaviot 3 Suunittelumallit 4 Suunnittelumallit Factory Method ja Abstract Factory 5 Suunnittelumallit Decorator ja Proxy
(ei-laajan kurssin kalvo: luento 10 sivu 2) Suunnittelumalli Mikä on suunnittelumalli (Design Pattern) Suunnittelumalli on tiiviisti esitetty yleinen kuvaus jostakin toimivasta ratkaisusta yleiseen ongelmaan. Suunnittelumallien ideoita voi käytettäessä soveltaa vapaasti. Malleja voi myös yhdistellä, ja niin usein tehdäänkin. Vertailukohtana voi ajatella vaikkapa erilaisia puuliitostapoja, tanssiliikkeitä, Niksi-pirkan vinkkejä jne. Suunnittelumalli kuvaa yleisen ratkaisutavan ja sovellusalue lopulta määrää sen kuinka mallia kulloinkin käytetään. 12:22
Sunnittelumallit ja olio-ohjelmointi yleensä suunnittelumallit liittyvät olio-ohjelmointiin useimmiten Java/C++-tyyppiseen: on rajapintoja, ei moniperintää, ei ensimmäisen luokan funktioita tai metodeja, ei dynaamisuutta suunnittelumallin idea toki toimisi muuallakin, mutta käytännössä niitä ei kovin usein näe yhtä vakiintunutta terminologiaa tai esitystapaa ei ole jotkut abstraktit funktiot (esim. fold-left) ovat mallien kaltaisia, mutta suoraan koodina monet tavallisimmista suunnittelumalleista ovat ratkaisuja juuri olio-ohjelmointiin liittyviin ongelmiin joskus esim. ensimmäisen luokan funktiolla tai muuten ei-olio-ohjelmoinnilla saisi tehtyä helpomman ratkaisun mutta varsinkin puhtaassa olio-ohjelmoinnissa suunnittelumalleista on paljon hyötyä
(ei-laajan kurssin kalvo: luento 10 sivu 3) Gang of Four Patterns Seuraavaksi käydään läpi joitakin kirjassa Gamma, Helm, Johnson, Vlissides : Design Patterns Elements of Reusable Object-Oriented Software, 1995 esiteltyjä suunnittelumalleja. Tässä kirjassa esitettyjä malleja kutsutaan yleisesti nimellä Gang-of-Four (GoF) patterns kirjan neljän kirjoittajan mukaan. Seuraavat kalvot perustuvat k.o. kirjaan. 12:22
(ei-laajan kurssin kalvo: luento 10 sivu 25) Iterator Monesti jonkin tietorakenteen kaikki alkiot tulisi käydä läpi (vaikkapa tallentaa tiedostoon) Tietoa voi kuitenkin olla monenlaisissa rakenteissa: puita, listoja, verkkoja jne. Iterator-rajapinta mahdollistaa rakenteen läpikäynnin ilman että sitä käyttävän tarvitsee tuntea rakenne Koska Pythonissassa on valmis rajapinta tälle (for..in..), kannattaa tätä mallia käyttävän aina käyttää mainittua rajapintaa. 12:22
Sisältö 1 Lisää ohjelmien suunnittelusta 2 UML-luokkakaaviot 3 Suunittelumallit 4 Suunnittelumallit Factory Method ja Abstract Factory 5 Suunnittelumallit Decorator ja Proxy
(ei-laajan kurssin kalvo: luento 10 sivu 7) Factory Method(function) Tehdasmetodi on metodi, jota käytetään olion luontiin Olion luokan nimeä ei tarvitse tietää, riittää kun tunnetaan rajapinta Käytännössä metodi toimii kuten olion luonti, palauttaen viittauksen halutun tyyppiseen olioon Voidaan toteuttaa kutsumalla konstruktoria metodin sisällä Voidaan palauttaa jokin olemassaoleva halutun tyyppinen olio Voidaan tehdä temppuja oliolle ennen kuin se palautetaan 12:22
(ei-laajan kurssin kalvo: luento 10 sivu 8) Factory Method Factory method mallia käytetään mm. kun: metodia kutsuva luokka ei itse voi tietää minkä aliluokan olion se haluaa luoda kun luotavat oliot halutaan parametrisoida ennalta kutsuvasta luokasta riippumatta esim. asetetaan käyttöliittymän nappuloille haluttu väri ja teksti automaattisesti. Asetukset tarvitsee säätää vain kerran kun olioita halutaan laskea, käytöstä poistettuja olioita kierrättää jne. Kierrätys - Konstruktorin kautta ei voi tarjota jo aiemmin luotua oliota -> tehdasmetodin kautta voi 12:22
(ei-laajan kurssin kalvo: luento 10 sivu 9) Factory Method class CardFactory( object ): def new_card( self, rank, suit ): if rank == 1: return Ace( rank, suit ) elif rank in [ 11, 12, 13 ]: return FaceCard( rank, suit ) else: return Card( rank, suit ) class Deck( object ): def init ( self ): factory= CardFactory() for suit in range(4): for rank in range(13): self.cards = factory.new_card(rank+1, suit) 12:22
Abstract Factory hieman laajempi suunnittelumalli Abstract Factory käyttää apuna edellistä siinä on useita erilaisia tehdasluokkia, ja niillä on yhteinen abstrakti yläluokka (jossa tehdasmetodi) usein kukin tehdasluokka tekee omanlaisiaan (eli eri aliluokan) olioita joskus samassa tehtaassa on useita tehdasmetodeita eri tarkoituksiin esimerkki: bouncy-0.6.20071104 pyglyph/font.py abstraktin luokan BaseFontFactory metodi get_font tekee uuden FontInstance:n abstraktin luokan perii LocalFontFactory jonka get_font hakee fontteja.ttf-tiedostoista tässä abstraktilla tehdasluokalla on vain yksi perillinen, ja siinä vain yksi tehtaan tuottama fonttiluokka: FontInstance:lla voisi olla aliluokkiakin
Sisältö 1 Lisää ohjelmien suunnittelusta 2 UML-luokkakaaviot 3 Suunittelumallit 4 Suunnittelumallit Factory Method ja Abstract Factory 5 Suunnittelumallit Decorator ja Proxy
(ei-laajan kurssin kalvo: luento 10 sivu 10) Decorator Mahdollistaa lisäominaisuuksien lisäämisen olioon lennossa, muuttamatta alkuperäistä luokkaa. Perusidea on, että dekoraattori liittää johonkin alkuperäiseen toimintoon oman lisänsä ja pyytää sitten koristelemaansa oliota (oli se sitten dekoraattori tai varsinainen olio) suorittamaan alkuperäisen toiminnon. Lopulta varsinainenkin operaatio tulee tehtyä Koska sekä dekoraattorit että varsinainen koristeltava olio noudattavat samaa rajapintaa, ovat dekoraattorit käyttävälle luokalle näkymättömiä. Reunustaja Värittäjä TodellinenOlio Käyttävä Luokka +operaatio() +omatoiminto() +operaatio() +omatoiminto() +operaatio() 12:22
(ei-laajan kurssin kalvo: luento 10 sivu 11) Decorator class Point(object): def init (self, x, y): self.x = x self.y = y def get_point(self): return (self.x, self.y) class ScalablePoint(object): def init (self, point_object, n): self.point_object = point_object self.scale = n def get_point(self): x, y = self.point_object.get_point() return (x * self.scale, y * self.scale) 12:22
(ei-laajan kurssin kalvo: luento 10 sivu 12) Proxy Proxy toimii jonkin toisen olion sijaisena ja säätelee olioon kohdistuvaa käyttöä. Kun jotain proxy-olion metodia kutsutaan, se yleensä kutsuu todellisen olion metodia Tyypillisesti sekä proxy-olio että oikea olio toteuttavat samaa rajapintaa, joten käyttävä luokka ei huomaa eroa Käyttötapoja : Proxyn kauttaa voidaan käyttää olioita jotka sijaitsevat aivan muualla (levyllä, verkossa jne.) (remote proxy) Lazy initialization: Proxyn suojaama olio voidaan alustaa vasta tarvittaessa. (virtual proxy) Proxyn avulla saman luokan eri olioille voidaan antaa 12:22 erilaiset näkyvyydet. (protection proxy)