Luento 8. Ohjelmistokehykset Tuoteperheet CSM14101 Ohjelmistoarkkitehtuurit

Transkriptio

1 Ohjelmistoarkkitehtuurit Luento 8 Ohjelmistokehykset Tuoteperheet CSM14101 Ohjelmistoarkkitehtuurit 1

2 OHJELMISTOKEHYKSET CSM14101 Ohjelmistoarkkitehtuurit 2

3 Ohjelmistokehykset (software frameworks) Osittain abstraktiksi jätettyjä ohjelmistorunkoja, joita eri tavoin täydentämällä saadaan rakennettua kokonaisia uusia sovelluksia tai sovelluksen osia Tavoitteena laajamittainen ja systemaattinen ohjelmistojen (sekä koodin että yleisrakenteen eli arkkitehtuurin) uudelleenkäyttö Olioperustaisissa kehyksissä ohjelmistorunko = kokoelma luokkia, komponentteja ja rajapintoja Ohjelmistokehykset sisältävät ohjelmakoodia, joten ne ovat sidoksissa ohjelmointikieleen Kehys on usein osa laajempaa ohjelmistoalustaa (platform) ja kehykseen voi kuulua omia työkaluja ja apuvälineitä CSM14101 Ohjelmistoarkkitehtuurit 3

4 Ohjelmistokehykset CSM14101 Ohjelmistoarkkitehtuurit 4

5 Ohjelmistokehykset Kehykset eroavat (luokka-, funktio-) kirjastoista (library) 1 Inversion-of-control: kehyksen sisäänrakennettu koodi ja sen logiikka ohjaa sovelluksen suoritusta (kontrollinkulkua), ei sovelluskohtainen koodi kuten luokkakirjastoja käytettäessä Oletustoiminnallisuus: kehys tarjoaa käyttökelpoista oletustoiminnallisuutta, ei pelkästään tynkätoteutuksia (no-ops, stubs) Laajennettavuus: kehyksen käyttäjä voi valikoiden syrjäyttää, erikoistaa tai lisätä kehyksen tarjoamaa toiminnallisuutta oman sovelluksena tarpeisiin kehyksen tekijän etukäteen määräämillä tavoilla Kehyksen muuttumaton koodi: kehyksen koodia ei ole (yleensä) tarkoitettu käyttäjän muutettavaksi - paitsi laajentamalla sitä tietyillä tavoilla erikseen määrätyissä kohdissa (kts. edelllinen kohta) [1] CSM14101 Ohjelmistoarkkitehtuurit 5

6 Ohjelmistokehykset Ohjelmoijan näkökulmasta usein: Kehys = API Teknisesti ajatellen kehys yleensä sisältää ja tarjoaa useita API:ja (rajapintoja) eri tarkoituksiin Rajanveto ei aina käytännössä ole kovin selvä, käytännössä monia kehyksiä kutsutaan yksinkertaisesti API:ksi Ensimmäinen laajalti käytetty ohjelmistokehys: Smalltalk- 80-ympäristön Model-View-Controller Alkuperäisen Model-View-Controller-kehyksen arkkitehtuurin pohjalta määritelty MVC-arkkitehtuurityyli Erityisesti käyttöliittymätoteutukseen on kehitetty useita kehyksiä työasemasovelluksiin, web-sovelluksiin, useille eri ohjelmointikielille, kaupallisia ei kaupallisia CSM14101 Ohjelmistoarkkitehtuurit 6

7 Ohjelmistokehykset Kehys voi olla kokonaisvaltainen koko sovellusta hallitseva tai osittaisongelmaan tarkoitettu tukikehys esim. käyttöliittymäkehykset rajautuvat käyttöliittymän toteutukseen, Java Enterpise Edition tarjoaa puitteet ja tuen kokonaisten yritysjärjestelmien toteuttamiseen (JavaEE on oikeastaan alusta eli platform, joka tarjoaa useita kehyksiä eri tarkoituksiin) Ns. sovelluskehykset on tarkoitettu tietyntyyppisten sovellusten toteuttamiseen Androidissa Java-sovelluksen rakenteen määrää ohjelmistokehys, joka on osa laajempaa käyttöjärjestelmään sisään rakennettua sovellusarkkitehtuuria Ohjelmistokehys ei ole valmis ohjelmistototeutus, vaan toteutus saadaan aikaan kehystä täydentämällä tai mukauttamalla CSM14101 Ohjelmistoarkkitehtuurit 7

8 Ohjelmistokehykset - termejä 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 (application framework) = kehys, josta voidaan erikoistaa kokonainen sovellus Komponenttikehys (framelet) = minikehys, jonka erikoistamisen tuloksena syntyy yksittäinen komponentti CSM14101 Ohjelmistoarkkitehtuurit 8

9 Ohjelmistokehykset - termejä 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 CSM14101 Ohjelmistoarkkitehtuurit 9

10 Ohjelmistokehykset - toteutus Erikoistamiseen voidaan käyttää esim. rajapintojen toteutusta (vrt. Dependency Inversion) periytymistä ja syrjäyttämistä (jos kieli tarjoaa) Kehyksen määrittelemien olioiden luontia ja kompositiota (yhteen kytkeminen ja konfigurointi, vrt. Dependency Injection) geneerisiä rakenteita myöhäistä sidontaa ja sitä tukevia rakenteita Sovelluskehyksissä päälogiikasta vastaa kehys ja sovelluskohtaiset erityistoimet toteutetaan täydennyksinä CSM14101 Ohjelmistoarkkitehtuurit 10

11 Ohjelmistokehykset - toteutus Sovelluskohtainen koodi täydennys täydennys täydennys Kontrolli- ja datavuo kutsu kutsu kutsu Staattinen riippuvuus (tässä periytyminen) Sovelluskehys Kutsuissa käytössä ns. käänteinen kutsurakenne = kehys kutsuu dynaamista sidontaa hyväksikäyttäen sovelluskohtaisia täydentäviä moduuleja (Hollywood-periaate: don t call us we call you) CSM14101 Ohjelmistoarkkitehtuurit 11

12 Ohjelmistokehykset - toteutus Kehyksissä sovelletaan tyypillisesti suunnittelupatterneja (design patterns) joustavuuden ja laajennettavuuden ynnä muiden hyvien asioiden saavuttamiseksi Joidenkin mallien soveltaminen on välttämätöntä kehyksen erikoistamismahdollisuuksien kannalta Kehyksen koodi sisältää tyypillisesti useiden suunnittelumallien ilmentymiä Alkuperäiset suunnittelumallit on löydetty analysoimalla olemassa olevia kehyksiä (esimerkiksi Smalltalk, HotDraw) Suunnittelumallit sopivat usein kehysten dokumentointiin [Johnson, 1992] Suunnittelupatterneissa on tyypillisesti helposti nähtävissä luontevasti kehykseen kuuluva osa (esim. abstraktit luokat) ja tuotekohtainen osa (esim. vaihtuvat konkreettiset luokat) CSM14101 Ohjelmistoarkkitehtuurit 12

13 Ohjelmistokehysten haasteita Tekninen vaativuus ja monimutkaisuus Arkkitehdin tunnettava hyvin sovellusalue ja joustavuuteen liittyvät oliotekniikat (esim. suunnittelumallit) Abstraktius voi tehdä kehyksestä erikoistajille hankalasti ymmärrettävän Kehysten yhdistely voi olla ongelma Mitä tehdään, jos halutaan käyttää useampaa kehystä, joista kukin määrittelee pääkontrollisilmukan? CSM14101 Ohjelmistoarkkitehtuurit 13

14 Ohjelmistokehysten haasteita 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 on erikoistamisrajapinnan kuvaus Tälle ei kuitenkaan vakiintunutta kuvaustapaa CSM14101 Ohjelmistoarkkitehtuurit 14

15 Ohjelmistokehysten haasteita Toteutuksen ongelmia Joustavien ratkaisujen toteuttaminen edellyttää asiantuntemusta (esim. suunnittelumallit auttavat) Joustavuus Ylläpito vaativaa monimutkaisuus, abstraktit käsitteet Testaus? (vrt. tuoterunkojen testaus) Käytön ongelmia Miten kehysten käyttö pitäisi dokumentoida? Keittokirjat (cookbooks) Suunnittelumallipohjainen dokumentointi Riittääkö tavanomainen dokumentaatio erikoistamisrajapinnan kuvaukseen? Työkalutuki sovellusten rakentamiseen JavaEE Spring Framework Spring Boot CSM14101 Ohjelmistoarkkitehtuurit 15

16 TUOTEPERHEET JA NIIDEN ARKKITEHTUURIT CSM14101 Ohjelmistoarkkitehtuurit 16

17 Tuoteperheet Määritelmiä: Tuoteperhe (product family, product line): toiminnaltaan ja rakenteeltaan samankaltaisten, tietylle sovellusalueelle toteutettujen ohjelmistotuotteiden muodostama joukko Tuoterunko (tai tuotealusta, product platform): ohjelmisto, joka toteuttaa tuoteperheen tuotteille yhteisen rakenteen ja toiminnallisuuden Tuoterunkoarkkitehtuuri (product-line architecture, PLA): tuoterungon ja siihen liittyvän tuoteperheen arkkitehtuuri Tuoterunkoarkkitehtuuriin katsotaan joskus kuuluvan mukaan myös ohjelmistot ja työkalut, joita käytetään apuna tuotteiden tekemisessä tuoterungosta

18 Tuoterunkoarkkitehtuuri Tuoterunkoarkkitehtuurin toteutuksen komponentteja voidaan hyödyntää kaikissa eri tuotteissa, mikä Parantaa laatua Koodi testattu useassa aiemmassa konfiguraatiossa Nopeuttaa ohjelmistokehitystä Valmiita komponentteja tarjolla Helpottaa projektin hallintaa Samankaltaiset tuotteet -> samankaltaiset projektit -> sama prosessi Standardoi tuotteita Runko antaa puitteet Tehostaa toimintaa, sillä perusarkkitehtuuri on suunniteltu ja toteutettu jo tuoterungossa

19 Eri tapoja toteuttaa ohjelmistotuote Yleiskäyttöiseen ohjelmointikieleen, DOL:ään (eli sovellusaluekohtaiseen kieleen) ja tuoterunkoon/ohjelmistoalustaan perustuva ohjelmistokehitys Tuoterunko:

20 Sovellusaluesuuntautunut ohjelmistotuotanto Tuoterungon suunnittelu Luodaan tuoterungon perusta olemassa olevan toteutuksen komponenteista Rakennetaan tuoterunko inkrementaalisesti: ensin vähän ominaisuuksia myöhemmin kattava tuoterunko Jos tuoteperheen tuotteet ovat kaikki uusia, voidaan rakentaa suoraan kattava tuoterunko Edellytyksenä kuitenkin sovellusalueen ja sen vaatimusten perusteellinen tuntemus (onko mahdollista ennen ensimmäisenkään tuotteen toteuttamista?) Otetaan ensimmäinen (uudentyyppinen) tuote tuoterungon perustaksi lisätään muunneltavuutta tarpeen mukaan Ohjelmistokehykset ovat yksi tapa toteuttaa tuoterunkoja

21 Muunneltavuus Keskeinen ongelma tuoterungossa: muunneltavuuden hallinta Tuoterungon toteuttavassa ohjelmistoalustassa on tyypillisesti mukana pakollisia, valinnaisia ja vaihtoehtoisia komponentteja Tuotteessa on mukana myös tuotekohtaisia uusia komponentteja

22 Muunneltavuus valinnainen valinnainen pakollinen vaihtoehtoinen vaihtoehtoinen, valittava Vaihtoehtoinen, joku näistä mahdollisesti tuotekohtainen eli voidaan korvata uudella uusi yhden tuotteen komponentti

23 Tuoterunkopohjainen ohjelmistokehitys

24 Tuoterunkopohjainen ohjelmistokehitys Tuoterunkopohjainen ohjelmistokehitys jakautuu kahteen eri osaan: alustakehitysprosessiin (domain engineering) tuotekehitysprosessiin (application engineering) Näitä edeltää esitutkimusvaihe Arvioidaan tuoteperheen kannattavuutta (vaikuttavana tekijänä erityisesti oletettava tuoteperheen tuotteiden lukumäärä), vrt. aiemmin esitetty laskennallinen malli Kannattaako rakentaa tuoteperhe vai toteuttaa perheeseen tulevat tuotteet erillisesti Vaatimusmäärittely (domain analysis) sovellusalueen käsitemalli (domain model), muunneltavuusvaatimukset, yhteiset vaatimukset Käsitemalli: kommunikointi, sanasto, ymmärtäminen Muunneltavuusvaatimukset: mitkä ominaisuudet voivat vaihdella, missä rajoissa, milloin muunnelma kiinnitetään (staattisesti koodausaikana, linkkausaikana, alustusaikana, tuotteen käytön aikana)

25 Tuoterunkopohjainen ohjelmistokehitys Tuoterunkoarkkitehtuurin suunnittelu (PLA design) Pohjana esimerkiksi esitutkimusvaiheessa kartoitetut arkkitehtuurityylit tai perinteisen oliosuunnittelun mukaan sovellusalueen käsitemalli. Iteratiivinen prosessi, jossa muunneltavuus keskeisessä asemassa Noudatetaan esimerkiksi aiemmin esitettyä arkkitehtuuripainotteista prosessia, jossa laatuvaatimuksia (tässä muunneltavuus) tarkastellaan yksi kerrallaan ja tarvittaessa muokataan arkkitehtuuria. HUOM! on varmistettava, ettei jo tehtyjä muunneltavuutta edistäviä ratkaisuja tuhota muiden vaatimusten mukaisten muutosten yhteydessä. Huom! Muunneltavuus eri tuotteiden välillä ei välttämättä tarkoita ulkoiselta toiminnaltaan toisistaan poikkeavia tuotteita (muunnettavuus esim. siirrettävyyden takia)

26 Tuoterunkopohjainen ohjelmistokehitys Konkreettisen toteutusympäristön suunnittelu (application engineering environment) Toteutusvälineistö (pelkkä tuoterunkoarkkitehtuurin kuvaus ja sen toteuttava alusta eivät yleensä riitä) Yksinkertaisin ratkaisu: tarjotaan hyvin määritelty API, joka piilottaa tuoterunkoarkkitehtuurin ja ohjelmistoalustan toteutuksen tuotteiden kehittäjiltä Usein tarpeen paljastaa osa tuoterunkoarkkitehtuurista kehittäjille (vrt. esim. white-box-tyyppinen uudelleenkäyttö sovelluskehyksissä) Ongelma: miten tuotteen vaatimukset mäpätään tuoterunkoarkkitehtuurin tarjoamiin ominaisuuksiin? dokumentointi, työkalutuki

27 Tuoterunkopohjainen ohjelmistokehitys Tuotekehitysprosessi Normaaliin tapaan ensin tuotteen vaatimusten kerääminen ja vaatimusanalyysi (haastattelut, etc.) välitetään asiakkaille tieto tuoterungon mahdollisuuksista Varsinaisen kehitystyön laatu riippuu hyvin paljon tuoterungon laadusta

28 Tuoterunkoarkkitehtuurin kerrosmalli tuotetuote Sovellusalusta Arkkitehtuurialusta Arkkitehtuurialusta Resurssialusta

29 Tuoterunkoarkkitehtuurin kerrosmalli Resurssialusta Yleisiä resursseihin (kommunikaatio, tietojen säilytys, prosessien hallinta, grafiikka) liittyviä peruspalveluja Arkkitehtuurialusta Yleisiä arkkitehtuurityyliin liittyviä palveluja Sovellusalusta Runko, sovelluskehys, patternit Sovellusalueen erityispiirteet, varianssipisteet Tuotekerros Tuotekohtaiset piirteet Vrt. Bob Martinin Clean Architecture

30 Tuoterunkojen haasteita Tyypillisimmät ongelmat eivät ole teknisiä: Suuri henkilöstön vaihtuvuus välttämättä motivoiva tuoterunkolähestymistapa ei ole Tuoterungon kehittäjillä liian kriittinen merkitys organisaatiossa Johto, markkinointi vs. tuoterungon kehittäminen Pitkän tähtäimen kehitystyöhön voi olla vaikeaa saada rahoitusta Tuoterungon tasapäistävä vaikutus: toisaalta liian monimutkainen toisaalta liian yksinkertainen

31 Tuoterunkojen haasteita Tuoterunkojen testaus on usein hankalaa Eivät itsenäisesti testattavissa (?) Usein jokainen toteutettava sovellus testataan erikseen Tuoterungon testaamiseen voidaan käyttää referenssisovelluksia, jotka käyttävät tuoterungon piirteitä kattavasti Testattavuuden helpottamiseksi saatetaan joutua rajoittamaan variaatiomahdollisuuksia Tuotteiden hallinta voi myös monimutkaistua: muutos alustaan kaikki eri tuotteet testattava (regressio) Ylipäänsä erilaisien riippuvuuksien dokumentointi tärkeämpää kuin täysin itsenäisissä sovelluksissa Jos tuotteet perustuvat alustan eri versioihin, halutaanko muutos kaikkiin alustaversioihin ja tuotteisiin vai ei? Bugikorjaus (kaikkiin?) vs. uusi ominaisuus (vain uusiin tuotteisiin?)