Ohjelmistokehykset Määritelmä & tavoitteet, taustaa & peruskäsitteitä, kehykset vs. suunnittelumallit, erikoistamisrajapinnat & kontrollinkulku, kehystyypit, kehysten rakenne ja evoluutio, esimerkki: JHotDraw, kehysten riskejä ja ongelmia 1
Ohjelmistokehykset Osittain abstraktiksi jätettyjä ohjelmistorunkoja, joita eri tavoin täydentämällä saadaan rakennettua kokonaisia uusia sovelluksia tai sovelluksen osia Suosittu tekniikka tuoterunkoarkkitehtuurien toteuttamiseksi Tavoitteena laajamittainen ja systemaattinen ohjelmistojen (sekä koodin että yleisrakenteen eli arkkitehtuurin) uudelleenkäyttö Tällä kurssilla puhutaan erityisesti olioperustaisista kehyksistä (kehyksen perusidea kuitenkin riippumaton ohjelmointiparadigmasta) Olioperustaisissa kehyksissä ohjelmistorunko = kokoelma luokkia, komponentteja, rajapintoja 2
Ohjelmistokehyksien taustaa Olioperustaisten ohjelmistokehysten historia alkaa 60- luvulta; ensimmäisen oliokielen, Simula67:n, toteutuksesta [Dahl et al., 1970; Nygaard-Dahl, 1981] Norjalainen kieli Suunniteltiin simulaatio-ohjelmistojen toteutukseen Sisälsi keskeiset olioparadigman piirteet: luokat, oliot, kapseloinnin, aliluokituksen, virtuaaliset operaatiot ja dynaamisen sidonnan Sisälsi valmiiksi määriteltyjä luokkakokoelmia, jotka voidaan tulkita ohjelmistokehyksiksi (esimerkiksi Simulation) 3
Ohjelmistokehyksien taustaa (2) Ensimmäinen laajalti käytetty ohjelmistokehys: Smalltalk- 80-ympäristön Model-View-Controller Alkuperäisen Model-View-Controller-kehyksen arkkitehtuurin pohjalta MVC-arkkitehtuurityyli MVC aloitti käyttöliittymäkehysten vyöryn, joka on jatkunut tähän päivään saakka Esimerkiksi: MacApp [Schmucker, 1986], Andrew Toolkit [Palay et al. 1988], InterViews [Linton et al., 1989], ET++ [Weinand et al., 1988], Swing [Sun Microsystems, 2001] Kaupallisia käyttöliittymäkehyksiä: zapp, OpenStep ja Microsoft Foundation Classes (MFC) 4
Ohjelmistokehyksien taustaa (3) Käyttöliittymäkehysten menestys (ja suuri määrä) leimasivat ohjelmistokehykset pitkäksi aikaa pelkästään käyttöliittymien toteutukseen soveltuvaksi tekniikaksi Ohjelmistokehyksiä on kuitenkin toteutettu hyvin moninaisille sovellusalueille Esimerkiksi: hypermediajärjestelmät, kaavioeditorit, käyttöjärjestelmät, kääntäjät, laskutusjärjestelmät, palohälytysjärjestelmät, laitetuotantolinjojen mittausohjelmistot, jne., jne Usein huomattavasti kiinteämmin sovellusalueesta riippuvia kuin käyttöliittymäkehykset 5
Ohjelmistokehykset: käsitteitä Ohjelmistokehyksen erikoistaminen (framework specialization, framework adaptation) = ohjelmiston (osan) toteuttaminen täydentämällä kehyksen tarjoamaa ohjelmarunkoa Abstraktien luokkien erikoistaminen, toiminnallisuuden koostaminen kehyksen konkreettisista luokista Sovelluskehys = kehys, josta voidaan erikoistaa kokonainen sovellus Komponenttikehys (framelet) = minikehys, jonka erikoistamisen tuloksena syntyy yksittäinen komponentti 6
Ohjelmistokehykset: käsitteitä (2) Laajennoskohta, variaatiopiste (hot spot, variation point) = kehyksen aukkokohta, jota täydentämällä voidaan sovelluksen puolella varioida ja/tai ottaa käyttöön tietty kehyksen toiminnallisuus/ominaisuus Erikoistamisrajapinta (specialization interface) = laajennoskohtien ja niihin liittyvien vaatimusten kokoelma Kehyksen erikoistamisrajapinta on tyypillisesti paljon monimutkaisempi kuin yksittäisen komponentin rajapinta Erikoistamisrajapinnan laajennoskohtien välillä on riippuvuuksia, joiden ymmärtäminen on edellytys kehyksen oikealle käytölle 7
Kehykset vs. suunnittelumallit Kehys on koodia, kun taas suunnittelumalli kuvaa erilaisia (luokka-, metodi- tms.) rooleja Kehyksen koodi sisältää tyypillisesti useiden suunnittelumallien ilmentymiä Alkuperäiset suunnittelumallit löydetty analysoimalla olemassa olevia kehyksiä (esimerkiksi Smalltalk HotDraw) Suunnittelumallit sopivat usein kehysten dokumentointiin [Johnson, 1992] Suunnittelumalleissa tyypillisesti kehykseen kuuluva osa (esim. abstraktit luokat) ja tuotekohtainen osa (esim. vaihtuvat konkreettiset luokat) 8
Kehykseen vs. sovellukseen kuuluvat osat suunnittelumalleissa = kehykseen kuuluva osa 9
Vierailija 10
Erikoistamisrajapinta ja kontrollin kulku 11
Erikoistamisrajapinta ja kontrollin kulku (2) B A Framework C Application Pääkontrolli ( main-silmukka ) kehyksen puolella (A). Takaisinkutsut sovelluksen puolelle (B). Kehyksen tarjoamien palveluiden kutsuminen (C). 12
Kehyslajit Abstrakti kehys Vain abstrakteja luokkia (tai rajapintoja); ei toiminnallisuutta 13
Muunneltava kehys Kehyslajit (white-box framework) Tarjoaa rajapinnat ja ohjelman päälogiikan 14
Pistokekehys Kehyslajit (plug-in framework) Erikoistetaan (miltei yksinomaan) rajapintoja; erikoistus tarjotaan yhtenäisenä plugin-komponenttina 15
Koottava kehys Kehyslajit (black-box framework) Koostetaan sovellus kehyksen tarjoamista valmiista komponenteista; ei takaisinkutsuja sovelluskoodiin 16
Kehysten rakenne ja evoluutio: iteratiivinen kehitys Framework Structure Framework Evolution Interface layer Interface * New/ more accurate requirements Framework core implementation layer AbstractClass New/ more accurate requirements Default component layer ConcreteClass New concrete implementations based on derived applications 17
Esimerkkikehys: JHotDraw Sovelluskehys rakenteisten kaavioeditoreiden toteuttamiseksi (www.jhotdraw.org) DrawingEditor Menubar DrawingView Tool Connector Handle Figure 18
Esimerkkikehys: JHotDraw JHotDraw-kehyksen rajapintakerros (yksinkertaistettu kuva) Handle * handles Connector end owner owner * start DrawingChangeListener * figsin selectedfigs Figure * figs ConnectionFigure DrawingView Drawing view Storable drawing gridsetting PointConstrainer Tool editor Editor currenttool 19
Esimerkkikehys: JHotDraw JHotDraw:n kerrosrakenne (esimerkkinä kahden keskeisen käsitteen kerrostuminen) Interface layer Figure Handle draw (Graphics g) getdisplaybox(): Rectangle setdisplaybox(rectangle) owner handles * draw (Graphics g) getdisplaybox(): Rectangle setdisplaybox(rectangle) AbstractFigure Core implementation layer AbstractHandle RectangleFigure Defaultcomponent layer RadiusHandle 20
Kehysten riskejä Tekninen vaativuus ja monimutkaisuus Arkkitehdin tunnettava hyvin sovellusalue ja joustavuuteen liittyvät oliotekniikat (esim. suunnittelumallit) Abstraktius voi tehdä erikoistajille hankalasti ymmärrettävän Kehysten yhdistely Mitä tehdään, jos halutaan käyttää useampaa kehystä, joista kukin määrittelee pääkontrollisilmukan? 21
Kehysten riskejä Monoliittisuus Kehys saattaa kasvaa suureksi ja hallitsemattomaksi Laadullinen varianssi Variaatiopisteet liittyvät useimmiten toiminnallisuuden muokkaamiseen Laatuominaisuuksia variointi sen sijaan yleensä hankalaa (esim. tietoturvan lisääminen, suorituskyvyn optimointi, ) Dokumentointi Olennaista erikoistamisrajapinnan kuvaus Tälle ei kuitenkaan vakiintunutta kuvaustapaa 22
Kehysten ongelmia Toteutuksen ongelmia Joustavien ratkaisujen toteuttaminen edellyttää asiantuntemusta (esim. suunnittelumallit auttavat) Joustavuus monimutkaisuus, abstraktit käsitteet Ylläpito vaativaa Testaus? (vrt. tuoterunkojen testaus) Käytön ongelmia Miten kehysten käyttö pitäisi dokumentoida? Keittokirjat (cookbooks) Suunnittelumallipohjainen dokumentointi Riittääkö pelkkä staattinen dokumentaatio? Työkalutuki sovellusten rakentamiseen (esim. laitoksella kehitetty JavaFrames-työkalu)? 23