T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty 1,2 26.11.2004 Jani Honkanen Lisää I1- vaiheen kokemuksia lisätty 1.3 29.11.2004 Mika Suvanto Pieniä muutoksia tekstiin 1.4 7.2.2004 Mika Suvanto I2 -vaiheen kokemukset Sisällysluettelo 1 Johdanto...2 2 Menetelmä... 2 3 Kokemukset...2 3.1 PP projektin suunnittelu...2 3.2 I1 ensimmäinen toteutusvaihe...2 3.2.1 Arviointi... 3 3.3 I2 toinen toteutusvaihe...3 3.3.1 Arviointi suunnittelumallien hyödyllisyydestä ja käytöstä...3 4 Viitteet... 4 Liite 1 Suunnittelumallien sovelluskohteita projektissamme...5 Creational...5 Structural...5 Behavioral...6 Sivu 1 / 7
1 Johdanto Valitsimme SEPA-aiheeksemme suunnittelumallit (design patterns [1]). Olemme kiinnostuneita suunnittelumenetelmistä ja päätimme kerätä kokemusta yleisesti tunnettujen suunnittelumallien soveltamisesta tämänkaltaisessa, paljon suunnittelua sisältävässä projektissa. Suunnittelumallit oppii myös varmasti paremmin muistamaan, kun niitä on hyödyntänyt käytännössä. Lisäksi Jani toimii ryhmässä arkkitehtina, mikä sopii hyvin suunnittelumallien soveltamista ajatellen. 2 Menetelmä Suunnittelumalleja käytetään sekä arkkitehtuurisuunnittelussa että ohjelmoinnissa. Tarkoitus on käydä itsenäisesti läpi ennen I1-iteraation alkua, millaisia suunnittelumalleja on olemassa ja hyödyntää niitä koko projektin ajan sopivissa paikoissa. Teknistä dokumentaatiota ja ohjelmakoodia kirjoitettaessa suunnittelumallit nimetään kirjan Design Patterns mukaan. Kunkin toteutusiteraation (I1, I2 ja FD) sekä teknisen spesifikaation valmistumisen jälkeen pohdimme seuraavia asioita: 3 Kokemukset Auttoivatko käytetyt suunnittelumallit hyvien suunnitteluratkaisujen löytämisessä? Helpottiko nimettyjen suunnittelumallien käyttö kommunikointia tai selkeyttikö se dokumentaatiota? Jäikö paikkoja, joissa olisi vielä voinut tehokkaasti hyödyntää jotakin suunnittelumallia? 3.1 PP projektin suunnittelu Suunnittelumalleja käytetään lähinnä matalamman tason toteutussuunnittelussa, joten emme hyödyntäneet niitä vielä PP-vaiheessa. 3.2 I1 ensimmäinen toteutusvaihe Projektissamme I1 -vaihe sisälsi pääasiassa toteutettavan järjestelmän suunnittelua. Varsinainen implementointi jäi suhteellisen vähäiseksi. Tämän vuoksi emme myöskään voineet käyttää suunnittelumalleja vielä täydessä laajuudessaan. Tähän mennessä käytetyt suunnittelumallit ja potentiaaliset käyttöpaikat on lueteltu liitteessä 1. Vaiheen aikana tutustuimme alueen perusteokseen Design Patterns [1] sekä lukuisiin www:stä löydettyihin esimerkkeihin ja tutoriaaleihin, kuten [2]. Arkkitehtuurisuunnittelun yhteydessä järjestelmä kuvattiin komponenttitasolla. Tämän kuvauksen yhteydessä pohdittiin myös suunnittelumalleja, joita kussakin komponentissa voisi soveltaa. Lista tästä on liitteessä 1. Sivu 2 / 7
Varsinaista koulutustilaisuutta emme aiheesta pidä suunnittelumallit ovat kuitenkin periaatteltaan ryhmälle tuttuja, joten ajan säästämiseksi koulutus järjestetään itseopiskeluna. Materiaalia tähän löytyy tästä dokumentista, teknisestä spesifikaatiosta sekä viitteistä [1, 2]. 3.2.1 Arviointi Suunnittelumallejen hyöty kommunikoinnissa ryhmän kesken on ollut vielä tässä vaiheessa projektia vähäistä. Todennäköisesti I2 vaiheen päätteeksi pystymme arvioimaan mahdollisen hyödyn paremmin, kun järjestelmän toteutus on edennyt pidemmälle ja saamme kerättyä kokemuksia koko ryhmältä. Itse suunnittelu/toteutustyössä ei suunnittelumalleista ole ollut vielä kovin suurta hyötyä muutamaa liitteessä 1 mainittua tapausta lukuunottamatta. Suunnittelumallien olemassaolo ei sinänsä auttanut suunnittelussa juuri lainkaan samankaltaiset suunnitteluratkaisut olisi luultavasti tehty myös ilman virallisiin suunnittelumalleihin tutustumista. 3.3 I2 toinen toteutusvaihe Toisessa iteraatiossa keskityttiin toteuttamaan järjestelmän keskeisiä toimenpiteitä, dokumentaatiogeneraattoria ja prosessin rakentamista kuvauskielestä. Järjestelmän arkkitehtuuri suunniteltiin ja runko toteutettiin jo ensimmäisessä toteutusiteraatiossa. Tässä vaiheessa tehdyt ratkaisut ovat osoittautuneet suhteellisen toimiviksi, sillä muutoksia ei ole juurikaan joutunut tekemään. Mm. Factory -mallin käyttö toimenpiteissä on varmasti hyödyttänyt jossain määrin koodin yhdenmukaisuutta ja ymmärrettävyyttä toisaalta, vaikka suunnittelumalleista ei olisi tiedetty mitään, toimenpiteiden rakenne hyvin todennäköisesti olisi varsin yhtenäinen. Prosessin latauksessa XML:stä on käytetty Builder- mallia, tosin rakenne on hieman tästä muokkautunut koodin lisääntyessä ja useiden ohjelmoijien lisätessä uusia ominaisuuksia. Rakentamisessa olisi kenties voinut käyttää jotakin muutakin mallia, kuten Visitor, vähintään yhtä hyvällä menestyksellä. 3.3.1 Arviointi suunnittelumallien hyödyllisyydestä ja käytöstä Myös tässä toteutusvaiheessa kokemukset suunnittelumalleista ovat pääosin samansuuntaisia kuin I1:ssä. Suunnittelumallien tuntemuksesta on varmasti hyötyä ohjelman arkkitehtuurin ja koodin rakenteen suunnittelussa, mutta toisaalta niitä ei kannata väkisin pyrkiä sovittamaan joka tarpeeseen. Tuntemalla suunnittelumallit on kuitenkin helpompaa luoda toimivia suunnitteluratkaisuja, vaikkei malleja tietoisesti pyrkisikään käyttämään. Suunnittelumallien kommunikointiin koko ryhmälle olisi voinut panostaa enemmän, mutta työmäärän ja aikataulujen paineessa tämä puoli jäi turhan heikoksi. Tällä tavalla kenties muutkin ryhmässä olisivat ottaneet malleja enemmän käyttöön. Toisaalta kovin montaa tällaista kohdetta ei ole, jossa malleja olisi selvästi voinut käyttää hyväksi. Sivu 3 / 7
4 Viitteet [1] Gamma, Helm, Johnson, Vlissides: Design Patterns, Addison-Wesley Professional 1995. [2] Design Patterns in Java - Reference and Example Site, http://www.fluffycat.com/java/patterns.html Sivu 4 / 7
Liite 1 Suunnittelumallien sovelluskohteita projektissamme Suunnittelumallit on luokiteltu Gamma et al. -ryhmän käyttämän luokittelun mukaan. Creational Abstract factory: EtlOperationFactory: toimenpidekomponenttien instanssit luodaan EtlOperationFactory.create()- metodilla, jonka jokainen toimenpidekomponentti toteuttaa. Tarkoitus on, että prosessin lataajakomponentti luo factory-oliot, minkä jälkeen jokaista prosessiajoa varten voidaan luoda create()-metodin avulla EtlOperation-rajapinnan toteuttava olio. Tämän olion toteutuksessa ei tarvitse silloin varautua siihen, että samaa oliota käytettäisiin useissa prosessiajoissa (helpotetaan toimenpidekomponenttien ohjelmointia). Hyöty on silti kyseenalainen, koska ei ole näköpiirissä mitään syytä, miksi prosessia ei voitaisi ladata jokaisella ajokerralla uudestaan ja luoda suoraan EtlOperation-olioita laatajakomponentista käsin. Builder EtlProcessBuilder: prosessin latauskomponentti toimittaa prosessin kuvauksen moottorille käyttämällä tätä rajapintaa. Lataaja pystyy luomaan prosessin osissa sitä mukaa kun se lukee kuvaustiedostoa (yksinkertaistaan lataajan rakennetta). Lisäksi mahdollistaa kuvauskielen helpon vaihtamisen. Factory method EtlOperationFactory.create (ks. edellä) Prototype Singleton Voitaisiin käyttää DatabaseManager-luokassa, mutta ei ole nähtävissä, että tätä luokkaa käytettäisiin kovinkaan monessa paikassa (suurin osa tietokantaa käsittelevästä koodista käyttää vain java.sql.connection:a tai Database-luokkaa). Structural Adapter Bridge EngineServices/OperationExecutor -> WorkingTableManager: Toimenpidekomponenteille tarjottavat väliaikaisvarastopalvelut on koottu EngineServices-rajapintaan, joka välittää metodikutsut edelleen väliaikaisvarastojen hallintakomponenteille. Mahdollistaa toimenpidekomponenteille tarjottavan rajapinnan tekemisen helppokäyttöiseksi ja käytännölliseksi ilman että väliaikaisvarastojen hallinnan rajapintaa tarvitsee monimutkaistaa. Composite Sivu 5 / 7
Decorator Facade EngineServices, ProcessBuilder, ProcessRun, EtlProcess: moottori tarjoaa joukon rajapintoja eri suuntiin, joiden kautta sitä käytettään. Moottorissa on rajapintoja niin monta, että on parempi erottaa ne selkeästi toteutusluokista. Flyweight Proxy WorkingTableManager DatabaseManager: "smart reference"-mielessä Behavioral Chain of responsibility Command Jos myöhemmin toteutetaan moottoriin monimutkaisempi aikataulutus toimenpiteille, niin command-patternista (eventeistä) voisi olla apua viestiliikenteen selkeyttämisessä. Interpreter Iterator Javan perusiteraattoreita käytetään runsaasti. Mediator ProcessRun-olio toimii koordinaattorina prosessiajon aikana, eli ohjaa keskitetysti useiden muiden olioiden toimintaa. Näitä olioita ovat OperationExecutor, WorkingDatabaseManager/WorkingTableManager, DatabaseManager sekä myöhemmässä vaiheessa tietovaraston lookup-taulujen käsittelyyn liittyvät komponentit. Tämä tuntuu helpottavan prosessin toimintalogiikan suunnittelua, kun se voidaan tehdä yhteen paikkaan (ProcessRun-olion sisälle). Memento Prosessin aikana tallennetaan välituloksia, joihin voidaan palata, jos prosessi keskeytyy Observer ProcessRun-olio tarkkailee toimenpidekomponenttien tilaa niiden ollessa käynnissä (OperationExecutor-olioiden kautta). State Jos toteutetaan monimutkaisempi prosessin aikataulutus, voisi olla hyötyä mallintaa se tilakoneena Strategy Sivu 6 / 7
Template method Visitor Sivu 7 / 7