Kehyksillä toteuttettujen tuotelinjojen rakenteellinen optimointi Pietu Pohjalainen Geneerinen metaohjelmointi Syksy 2004 Tietojenkäsittelytieteen laitos Helsingin yliopisto
Esityksen sisältö Oliopohjaiset kehykset Tuoteperhe-arkkitehtuurit Ongelmakohtia mobiiliohjelmointiin sovellettaessa Ratkaisuehdotus Empiirisiä havaintoja
Oliopohjaiset kehykset Oliopohjaisia kehyksiä käytetään ohjelmakoodin uudelleenkäyttöön Jako sovelluskehyksiin (application framework) ja kehyskomponentteihin (framework component) Sovelluskehystä käyttäessä kehyksen erikoistus vastaa täydellistä sovellusta Kehyskomponenttia käyttäessä erikoistettuja ohjelmia käytetään muiden ohjelmien osana
Muunneltavat kehykset Tavallinen muoto on muunneltava kehys (white-box framework) Käyttö tapahtuu perimällä kehysluokkia ja/tai toteuttamalla kehyksen rajapintoja
Muita kehyksien jaotteluita Myös muita kehyksien jaotteluita nähdään, esim [Taligent 1995], Sovelluskehyksiin, Ongelma-alue kehyksiin (domain frameworks) Tukikehyksiin (support or utility frameworks) Joidenkin mielestä jopa MVC on kehys
Hollywood-periaate Perinnän kautta erikoistetuissa kehyksissä Hollywood-periaate Don't call us, we'll call you Sovellus Uudelleenkäytettäviä moduuleita Sovelluskehys Sovelluskohtainen koodi Uudelleenkäytettävä koodi
Tapa toteuttaa tuotelinjaarkkitehtuuri Esimerkkejä sovelluskehyksistä Javan AWT ja Swing Esimerkkejä kehyskomponenteista Javan Collections Oliopohjaisella sovelluskehyksellä voidaan toteuttaa tuotelinjaarkkitehtuuri
Tuotelinja-arkkitehtuuri Engl. product-line architecture Tavoitellaan systemaattista uudelleenkäyttöä suunnittelemalla sovellusaluetta ns. domain-mallinnuksella Sovellusten välinen variaatio kiinnitetään variaatiopisteisiin
Nokian tuotelinja Perusplatform SymbianOS Laajennokset NokiaUI 1.0 NokiaUI 2.0 NokiaSound Series 60 Series 40 Series 80 Tuoteplatformikohtaiset lisäykset (UI-kerros) Tuoteohjelmat (A-P Tuovinen)
Siirrettävän sovelluksen tuottaminen? Nokia Siemens Oma sovellus Motorola
Perustetaan oma tuotelinja Domainmallinnuksessa käydään läpi olemassa olevat tuotteet joille oma sovellus tulisi olla siirrettävissä Ratkaisu:
Huonoja puolia Huonona puolena oliokehys tuottaa turhia väliluokkia Koskimies huomauttaa Oliokirjassa (s. 266) Kehyksellä voi olla myös vaikea tuottaa pieni, riisuttu sovellus (esimerkiksi rajoitetulla muistilla varustettuun suoritusympärisöön): sovelluskehyksellä tuotetettu sovellus saattaa sisältää kehyksen perusvälineistön, vaikka sitä ei käytettäisikään.
Turhat välirajapinnat MIDI- ja tavalliset äänet eristävä rajapinta kätevä tapa toteuttaa Lopullisessa levityspaketissa kuitenkin valitaan vain toinen toteutus
.. voidaan poistaa Samaan tapaan kuin funktioita ja vakioita voidaan laventaa Voidaan myös rajapintamäärittelyitä laventaa
Milloin Soveltamalla levityspaketin kokoamisen yhteydessä ohjelmatason analyysiä (Whole-program analysis) Voidaan luokkahierarkiaa tutkia (Classhierarchy analysis) Löydettäessä rajapintaluokka, jolla on vain yksi toteuttava konkreettinen luokka Voidaan rajapintaluokka poistaa
Miten Täsmällisemmät algoritmit esitetään paperissa Ideana vaihtaa tyyppimäärittely kaikista käyttöpaikoista Käyttöpaikkoja Paluuarvot Argumentit Jäsenkentät Kutsukohdat Kenttien käyttökohdat Lisäksi peittyvien kenttien kanssa oltava tarkkana
Laajennettavissa myös abstrakteihin luokkiin Samaan tapaan voidaan analyysiä soveltaa abstrakti luokka konkreettinen luokka -yhteyteen Jos abstraktin luokan toteuttaa vain yksi konkreettinen luokka, Voidaan ne laventaa yhdeksi
Entä onko käytännöllinen Alustavasti kyllä: Suunnittelumallit Abstract Factory Template Method tuottavat tällaisia rakenteita oikeasti?
Toteutus Idean kokeilemiseksi tehty optimoinnin toteuttava prototyyppi Javan luokkatiedostojen käsittelemiseen käytetään Apache BCEL -kirjastoa Yhteensä noin 7,000 riviä koodia Josta itse optimointien toteutus noin 2,000 riviä
Paljonko tilaa säästyy? Rajapintojen laventamisessa tilaa säästyy: Pienentyneen luokkahierarkian ansiosta Asiakasluokkien symbolitaulun pienentymisessä Jokaisessa kutsukohdassa Abstraktin luokan laventamisessa lisäksi Syrjäytettyjen metodien pois jättämisellä
Empiirinen kokeilu Tilanvienti riippuu pääasiassa symbolitaulun koosta Testissä 64kB kokoinen J2MEpeli, jossa neljä rajapintaa Säästöä 2,200 tavua
Huomattavaa Menetelmän käyttöaika oleellinen Voidaan toteuttaa vasta kokoonpanovaiheessa, kun koko ohjelman toimintaa koskeva 'wholeprogram analysis' mahdollista Vaatii lisäksi 'closed world'-oletuksen: Käyttäjän määrittelemien luokkalataajien tulee olla kiellettyjä Tämä pitää paikkansa J2ME/MIDP:issä
Jatkosuunnitelmia & yhteenveto Tällä hetkellä käytössä osana käännösprosessia suomalaisessa pelitalossa Abstraktien luokkien laventamisen toteutus vielä kesken Analyysien tarkkuutta voi parantaa, kirjallisuudesta löytyy mielenkiintoisia esimerkkejä Harmittavasti laitoksella ei näitä asioita enää ymmärretä :-(
Seminaaritekstin lisäksi lähteitä [Taligent 1995]: Adair, Deborah: Building Object-Oriented Frameworks, Taligent Inc. [Oliokirja 2000]: Koskimies, Kai: Oliokirja