SEPA - Design Patterns

SEPA - Design Patterns Kimmo Karlsson, 51066R & Antti Pirinen, 51406N 15. maaliskuuta 2005 1 Sisältö 1. Sisältö 2. Johdanto 3. Käyttöönotto 4. Käyttökokemukset 2 Johdanto Valitsemamme ohjelmistonkehityskäytäntö (Software Engineering Practice Assignment, SEPA) on Design Patterns. Sujuvaa suomennosta on vaikea löytää (Suunnittelumalli = Design Model), joten käytämme englanninkielistä termiä. Design Patternit ovat yleisiä ja hyväksi havaittuja ohjelmiston toteutusratkaisuja. Niiden käyttö on suositeltavaa ohjelman ymmärrettävyyden kannalta. Myös ohjelmiston kokonaisarkkitehtuuri pysyy selkeänä käytettäessä tuttuja Design Patterneja. Lähteinä käytämme ainakin seuraavia: Craig Larman: Applying UML And Patterns, 2nd edit., 2002, Prentice Hall James Cooper: Java Design Patterns (1st draft, 2004) (cache) Projektimme luonteen takia tuottamamme ohjelmiston ylläpidettävyys on tärkeällä sijalla, ja ohjelman selkeä rakenne on yksi osa sitä tavoitetta. Käyttämällä Design Patterneja ohjelmamme rakenne pysyy helpommin ymmärrettävässä muodossa. 1

4 KÄYTTÖKOKEMUKSET 3 Käyttöönotto Tämä käytäntö liittyy jonkin verran suunnitteluun ja ennen kaikkea toteutukseen. Siksi kaikkien matalan tason suunnittelua ja toteutusta tekevien on syytä ottaa työssään huomioon Desing Patternit. Arkkitehtuuritasollakin on hyvä ymmärtää, mistä Design Patternista on kyse, vaikka projektissamme arkkitehtuuri onkin suurelta osin saneltu valmiiksi. Esitietokartoituksen perusteella Design Patternit eivät ole tuttuja kaikille ryhmämme jäsenille, joten pyydämme suunnitteluun ja toteutukseen osallistuvia tutustumaan I1-iteraation aluksi ainakin edellä mainittuun www-sivuun. Tässä vaiheessa projektia emme vielä päätä, mitkä Design Patternit ovat tämän projektin kannalta oleellisia. Suunnittelun edetessä tulee kyllä selväksi, mitä Design Patterneja kannattaa käyttää. Voimme vain esittää arvion, että tulemme käyttämään ainakin Model-View-Controller-, Observer- ja Singleton-Design Patterneja. 4 Käyttökokemukset 4.1 Projektin suunnittelu Tässä vaiheessa emme vielä käyttäneet Design Patterneja, koska suunnittelu eteni niin korkealla tasolla. 4.2 Implementation 1 Tutustuttuamme lähemmin Eclipsen arkkitehtuuriin, meille selvisi, ettei kovin paljon arkkitehtuuriratkaisuja pysty itse tekemään. Eclipsen API sisältää oman ratkaisun melkein kaikkiin ohjelmistomme tarvitsemiin ominaisuuksiin. Design Patterneja jonkin verran tuntevina pystyimme kuitenkin nopeasti ymmärtämään arkkitehtuuriset ratkaisut ja miten niitä hyödynnetään. Design Patternit, joita etukäteen suunnittelemamme käytettäväksi tässä projektissa, eivät ole ainakaan vielä olleet hyödyllisiä. Tähän mennessä hyödynnetty: Design Pattern: Front Controller (myös: Facade) Kuvaus: Kokonaisen alijärjestelmän rajapinnaksi tehdään yksi luokka, jonka julkisina metodeina ovat alijärjestelmän toiminnot. Front Controller - luokka ottaa käyttöön tarpeen mukaan alijärjestelmän luokkia, mutta ei anna paluuarvona näiden luokkien instansseja. Hyöty: Alijärjestelmän toteutus saadaan tehokkaasti piilotettua alijärjestelmää käyttäviltä ohjelman osilta. Muutokset alijärjestelmän sisällä eivät heijastu koko ohjelmaan. 2

4.3 Implementation 2 4 KÄYTTÖKOKEMUKSET Builder -osuus ohjelmastamme käyttää tätä Design Patternia. Eclipselle rekisteröidään yksi luokka, jonka metodia kutsutaan projektin rakentamisessa. Latex-dokumentti voidaan kuitenkin prosessoida monella tavalla, joten Front Controller:ina toimiva luokka instantioi tarpeen mukaan erilaisia dokumentinprosessointiluokkia ja kutsuu niiden metodeja. 4.3 Implementation 2 Tässä vaiheessa projektia toteutimme suurimman osan ohjelman toiminnallisuudesta. Tutkimme lähinnä niitä Design Patterneja, jotka esiintyivät itse toteuttamissamme osissa ohjelmaa. Vaikka varsinaista arkkitehtuuria ei tällaiseen plugin-tyyppiseen ohjelmaan saadakaan toteutettua, sisältää ohjelmamme niin paljon toiminnallisuutta että Design Patterneja voi soveltaa monessa yhteydessä. Otimme muutaman Design Pattern:in lisää käyttöön: Design Pattern: Factory Kuvaus: Jonkin rajapinnan toteuttavia luokkia ei oteta käyttöön suoraan, vaan jokin (yksi) luokka on vastuussa instanssien luomisesta. Hyöty: Luotavista instansseista voi olla useita eri implementaatioita eikä Factoryluokkaa käyttävien luokkien tarvitse tietää asiasta mitään. Design Pattern: Observer Builder: Erityyppisten dokumenttien rakentamiseen on olemassa erilaisia implementaatioita Builder-rajapinnasta. BuilderRegistry-luokka hoitaa niiden käsittelyn. Kuvaus: Jonkin objektin tilaa halutaan tarkkailla. Tarkkailtavalle objektille annetaan erityisen Listener-rajapinnan toteutuksia. Tarkkailtava objekti kutsuu Listener-rajapinnan metodia tilansa muuttuessa. Hyöty: Abstraktion lisääminen ja eri luokkien implementaatioiden erottaminen toisistaan. Builder: Dokumentin rakennuksen aikana käyttäjälle näytetään prosessin etenemistä kuvaava palkki, jossa on myös cancel-nappi. Tämän napin painalluksen tulee aiheuttaa prosessin keskeytyminen. Nappille annetaan erityinen CancelListener-olio, joka hoitaa hallitusti prosessin keskeytyksen. 3

4.3 Implementation 2 4 KÄYTTÖKOKEMUKSET Viewer: Erillisen ohjelman ajon aikana ohjelman tulostusvirtaa lukeva olio ilmoittaa kohtaamistaan ns. inverse search tapahtumista editorille, joka osaa navigoida oikeaan kohtaan lähdekoodissa. Ilmoitukseen käytetään erityistä FileLocationListener-rajapintaa. Design Pattern: Composite Kuvaus: Mahdollistaa tietyn rajapinnan toteutuksille yhtenäisen käsittelyn. Hyöty: Yksinkertaisempi sovelluslogiikka, esim yksittäisen alkion ja listan käsittelyyn ei tarvitse kirjoittaa erikseen käsittelyä. Design Pattern: Singleton Builder: Joskus käyttäjä haluaa rakentaa Latex-dokumentin suoraan lähdekoodista pdf-formaattiin. Joskus taas joudumme rakentamaan ensin dvi-formaatin tiedosto, tämän jälkeen dvi:stä pdf. Tähän tilanteeseen on varauduttu toteuttamalla jotkin Builder-rajapinnan instanssit Composite -patternilla. Kuvaus: Luokasta on olemassa vain yksi instanssi, joka on koko ohjelman käytössä ja haettavissa luokasta jonkin julkisen metodin kautta. Hyöty: Mahdollisuus toteuttaa jokin yksinkertainen globaali tietovarasto siten, että ohjelmassa on vain yksi tietovarastoon liittyvä staattinen muuttuja. Näin ohjelman kaikki osat pääsevät käsiksi samoihin tietoihin sekä voimme myös säästää muistia käyttämällä tätä samaa instanssia koko ohjelman suorituksen ajan. Builder: Dokumentin rakentamisessa voi olla monia vaiheita. Jokaista vaihetta kuvaa yksittäinen ProgramRunner-olio. Näiden olioiden hallintaan ja instantiointiin on toteutettu erityinen BuilderRegistryluokka, jolta voidaan pyytää halutun vaiheen toteuttava ProgramRunner (esim. dvi2pdf-vaihe). Viewer: Ulkoiset dokumentin katseluohjelmat, kuten Yap, kommunikoivat käyttäjän navigoinnin dokumentissa takaisin editorille jonkin tietoliikenneportin kautta. Porttiin tarvitaan pieni palvelinohjelma, joka toisaalta kommunikoi Yap:n kertomat tiedot takaisin Latex-koodia näyttävälle editorille. Palvelimen ollessa Singletonpatternilla toteutettu, sitä on helppo komentaa, ja asetettu portti pysyy varmasti tämän ohjelman hallussa. 4

4.4 Finalization and delivery 4 KÄYTTÖKOKEMUKSET 4.4 Finalization and delivery Design Patterit ovat mielestämme tuoneet ohjelmaan selkeyttä ja joissain tapauksissa jopa toimintavarmuutta. Näin voisi päätellä ainakin bugien määrästä niissä osissa ohjelmaamme, joissa Design Patterneja ei ole aktiivisesti hyödynnetty (lähinnä viewer-moduuli). Luettelemme tässä muutaman aikaisemmin huomaamatta jääneen Design Patternin. Lisäsimme myös käyttötapauksia aikaisempien vaiheiden Design Pattereihin. Design Pattern: Command Kuvaus: Erilaisia toimintoja voidaan kutsua saman rajapinnan kautta, välittää moduulilta toiselle ja vaihtamaa kesken ohjelman suorituksen. Hyöty: Ohjelman eri osien riippumattomuus toisistaan kasvaa, kun joka paikassa kutsutaan vain yhtä metodia samasta rajapinnasta. Design Pattern: Proxy Builder: Latex-dokumentin rakentaminen esim. PDF-muotoon sisältää monta vaihetta: tex-muodosta dvi-muotoon, dvi:stä ps-muotoon ja ps:stä pdf-muotoon. Jokaisen vaiheen kuvaaminen Command-tyypisenä oliona toi selkeyttä koodiin. Kuvaus: Luokkaa käytetään välillisesti toisen luokan avulla. Hyöty: Piilotetaan ylimääräistä toiminnallisuutta muulta ohjelmalta. Voidaan myös piilottaa verkon yli tapahtuva kommunikaatio. Design Pattern: Visitor Parser: Kielioppikuvauksesta generoituun LatexParser-luokkaan on lisätty toiminnallisuutta TexParser-luokkaan. TexParser-luokkaa käytetään ohjelmasta käsin, ja suurin osa TexParser-luokan toiminnallisuudesta on oikeasti LatexParser-luokassa. Kuvaus: Rajapinta, jonka toteuttava luokka osaa suorittaa jonkin operaation usean samanlaisen luokan instansseille. Hyöty: Tyypillisesti juuri puurakenteen läpikäynnissä käytetään Visitor-patternia. Koko rakenne voidaan silloin käydä läpi yksinkertaisessa silmukassa ja suorittaa sama komento jokaiselle solmulle. 5

VIITTEET VIITTEET Outline: Dokumentin rakennetta näytettäessä, voidaan jotkin rakenneosat, esim. alialiotsikot (subsubsection) jättää näyttämättä. Tämän takia rakennenäkymän päivityksen yhteydessä tarkistetaan jokaisen hierarkkian osan tyyppi. Rakennehierarkkian läpikäyntiin käytetään Visitor-tyypistä luokkaa. Design Pattern: Model-View-Controller Kuvaus: Arkkitehtuurin kuvaamisessa paljon käytetty malli, jossa toiminnallisuus jaetaan kolmeen osaan: Model: sisältää datan ja sen manipulointiin liittyvät toiminnot View: sisältää datan esittämiseen ja visualisointiin liittyvät toiminnot Controller: sisältää sovelluslogiikan, ja ohjaa datanmuokkauskomennot Modelille sekä datan visualisointikomennot View:lle Hyöty: Arkkitehtuurin eri osat on helpompi erottaa toisistaan ja niiden esim. datan erottaminen visualisoinnista tuo koodiin hyödyllistä riippumattomuutta. Editor: Keskeinen osa Eclipsen tiedosto-editoria on toteutettu tällä Design Patternilla. View-osana toimii pluginin toteuttama Outlinekomponentti ja toisaalta myös TextEditor-komponentti, joka on suurimmaksi osaksi Eclipsen toteuttama. Controller-osana toimii pluginin toteuttama luokka, joka tarvittaessa kertoo Outlinelle rakenteen päivitystarpeesta. Model-osana toimii Eclipsen tarjoama IDocument-rajapinnan toteuttama luokka, joka sisältää dokumentin tekstin sekä tarjoaa tekstin muokkaamiseen ja etsintään tarvittavat metodit. Yhteenvetona voidaankin todeta, että desing patternejen hyödyntämismahdollisuudet ovat hyvin moninaiset. Aloittelevalle ohjelmoijalle onkin ehkä haastavanmpaa huomata kaiki ne patternit, joita hän on tietämättään käyttänyt. Vasta sen jälkeen, kun hän ymmärtää patterninen idean, hän pystyy siistimään koodiaan niin, että koodi toteuttaa tietyn patternin muodon. Vasta tämän jälkeen hän pystyy hyötymään valmiiksi mietitystä ongelman ratkaisusta. Viitteet [1] Bernard Collins, Design Patterns Java Companion, Addison-Wesley, 2004 [2] Craig Larman, Applying UML and Patterns, Prentice-Hall, 2002 6