Ohjelmistoarkkitehtuurit Luento 1 1 Oppimistavoitteet Mitä ohjelmistoarkkitehtuuri on? Rakenteita korostava näkökulma Suunnittelupäätöksiä korostava näkökulma Arkkitehtuurin käyttö ja hyödyt Kuinka paljon "arkkitehtuuria" tarvitaan? Riskilähtöinen arkkitehtuurityö 2 1
ALUKSI 3 Sovellusten määrä USA:ssa eri vuosikymmeninä (arvio)* 6000000 Applications 5000000 4000000 3000000 2000000 Appls. (est.) 1000000 0 1960 1970 1980 1990 2000 2010 2020 * ) Capers Jones, The Technical and Social History of Software Engineering. Addison-Wesley Professional, 2013. 4 2
Sovellusten keskim. koko USA:ssa Function Point -kokomittarilla (arvio)* 1200 1000 800 600 400 Avg. Function Points Logical stmts per FP 200 0 1950 1960 1970 1980 1990 2000 2010 * ) Capers Jones, The Technical and Social History of Software Engineering. Addison-Wesley Professional, 2013. 5 1995 1990 1985 1980 1970 Ohjelmistotekniikan kehityksestä 2010 Websovellusalustat, HTML5, pilvipalvelut, mobiili, Bigdata, IoT, Continuous X, kontit, mikropalvelut Tuoteperhearkkitehtuurit, MDA, väliohjelmistot, 2000 ohjelmistoalustat, aspektit, dynaamiset (skripti-) kielet, virtualisointi, palveluarkkitehtuurit (SOA) CASE-välineet: uudelleenkäyttö, testaus, mittaus Patterns (ratkaisumallit), sovelluskehykset, ohjelmistoarkkitehtuurit, arkkitehtuurityylit, arkkitehtuurien kuvauskielet, UML CASE-välineet: käyttöliittymien piirtäminen CASE-välineet: kaaviotyökalut (oliotekniikat) CASE-välineet: koodingenerointi (5GL) Oliot, uudelleenkäyttö, oliosuunnittelu, tietokone- ja järjestelmäarkkitehtuuri, relaatiotietokannat (4GL) Suunnittelumenetelmät: tietovirtakaaviot, ER-malli Modulaarisuus, tiedon kätkeminen, (2GL, 3GL) 1950-60 Aliohjelmat (1GL) Lean, ekosysteemit, startupit, experimentointi Ketterät menetelmät (agile methods) Liiketoiminta, organisaatio, Unified Process & inkrementaalinen kehitys Graafiset käyttöliittymät, käytettävyys Prosessit: CMM, spiraalimalli & riskien hallinta Prosessit: vesiputous 6 3
Ohjelmistojen merkityksestä 2010-luvun tietoyhteiskunta: lukematon määrä palveluita toteutetaan tietojärjestelminä, joista monet ovat kooltaan ja käyttäjämääriltään maailmanlaajuisia Tietokonelaitteistot kehittyneet huimasti: laskentateho, nopea tiedonsiirto, valtavien tietomäärien hajautettu tallennus ja rinnakkainen käsittely, esineiden Internet Virtualisoinnin ja pilvestä saatavan laskenta- ja tallennuskapasiteetin ansiosta kokonaisia järjestelmiä voidaan toteuttaa nyt puhtaasti ohjelmistoratkaisuina (ei omia kiinteitä laiteja infrastruktuuri-investointeja) Laadultaan hyvien ohjelmistojen kustannustehokas toteuttaminen on entistäkin tärkeämpää Tarkoituksenmukaisuus, tehokkuus, luotettavuus, saatavuus, käyttökokemus, muunneltavuus, skaalautuvuus, turvallisuus,. Kilpailu on kovaa ja markkinat avoimet, time-to-market Ohjelmistoarkkitehtuuri on tärkeässä roolissa halutun laadun ja tuottavuuden saavuttamisessa 7 OHJELMISTOARKKITEHTUURI 8 4
Määritelmiä Ohjelmistotyyppien kirjo on hyvin suuri Sulautetut ohjelmistot pienlaitteissa gigaapplikaatiot webissä miljoonine yhtäaikaisine käyttäjineen Myös ohjelmistoarkkitehtuuri on osoittautunut monitahoiseksi asiaksi, jota voidaan perustellusti tarkastella eri näkökulmista ja eri tavoittein Johtaa hieman erilaisiin määritelmiin ja painotuksiin Kaksi koulukuntaa (1990 s 2010 s) Rakenteita korostava koulukunta Suunnittelupäätösten merkitystä korostava koulukunta 9 Rakenteet <> Suunnittelupäätökset Rakenteet Kattavuus Dokumentaatio Suunnitelmallisuus - Hallinta Http server App Application Logger Browser Client REST, JSON, HTML5 Data store Server Client- Server, 3-Tier Rabbit MQ Suunnittelupäätökset Ominaisuudet Ymmärrys Inkrementaalisuus 10 5
I - Rakenteita korostava määritelmä Software Engineering Institute / Carnegie Mellon University: The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Järjestelmän ohjelmistoarkkitehtuuri tarkoittaa rakenteita, joita tarvitaan päätelmien tekemiseksi järjestelmästä ja sen ominaisuuksista. Rakenteet koostuvat ohjelmistoelementeistä, niiden välisistä suhteista, ja näiden molempien piirteistä. (Katso myös esimerkiksi ISO/IEC 42010 standardin arkkitehtuuurin määritelmä https://en.wikipedia.org/wiki/iso/iec_42010 ja IEEEXplore) 11 Mitä rakenteet ovat? Määritelmä jättää tämän avoimeksi Ei yksi vaan joukko rakenteita Mikä tahansa tarkoituksenmukainen kokoelma elementtejä ja niiden välisiä suhteita voi muodostaa rakenteen Ohjelmistoja on monenlaisia ja monenkokoisia! Kurssilla opimme, minkälaisia rakenteita yleensä kannattaa tarkastella (arkkitehtuurin mallinnus) Rakenteiden valinta riippuu sovelluksesta, sovellusalueesta ja toteutusteknologioista, one size does not fit all 12 6
Tyypillisiä elementtejä ja rakenteita Ohjelmistolla on kolme olomuotoa, joissa esiintyy merkittäviä rakenteita Staattinen, dynaaminen, operatiivinen Staattinen olomuoto Ohjelmiston koodi tiedostoissa ja tiedostojärjestelmän kansioissa - muodostaen toisistaan erillisiä kokonaisuuksia eli moduuleja konfiguraatio- ynnä muut alustus- ja datatiedostot ja resurssit Moduulien väliset sisältyvyys ja viittaussuhteet (tiedosto- ja kooditasolla) eli riippuvuudet (dependency) 13 Tyypillisiä elementtejä ja rakenteita Dynaaminen olomuoto Ohjelmiston suoritusaikana (tietokoneen muistiin ja käyttöjärjestelmään) luomat aktiiviset ja passiiviset oliot, prosessit ja säikeet, data-entiteetit sekä näiden kommunikaatiorajapinnat ja yhteydet Olioiden (ja prosessien) jakamat muistialueet ja k.järj. -resurssit, muut viestintä- ja yhteistoimintamekanismit Virtuaalikoneet, muut suoritusympäristöt (esim. kontit) Usean olion muodostamat, roolinsa ja toimintansa perusteella selkeästi erottuvat, rajapinnoin toisistaan eristetyt kokonaisuudet (alijärjestelmä, komponentti) ja niiden väliset yhteydet Application, Server, Load Balancer, Business Process, Container, Bean Palvelu Olio- ja prosessijoukko Huomaa: ei välttämättä yksi-yhteen vastaavuutta staattisten rakenteiden kanssa 14 7
Tyypillisiä elementtejä ja rakenteita Operatiivinen olomuoto (sijoittelu, allokaatio) Dynaamisten olioiden ja palveluiden sijoittelu ja suoritus laitteistossa osana tiettyä järjestelmää (Virtuaali-) palvelimet, tallennusvälineet, tietoliikennekanavat Palveluiden ylös- ja alasajo, päivitykset, monitorointi, skaalautuvuuden ja saatavuuden hallinta, pääsynvalvonta, transaktiot Ohjelmiston paketointi (packaging), konfigurointi ja piirteiden (features) valinta tiettyä käyttökontekstia (asiakasta) ja jakelua varten (komponentit) 15 Pohdittavaksi Mitä elementtejä ja rakenteita voisi olla Javasovelluksessa? Staattinen, dynaaminen, operatiivinen olomuoto 16 8
Abstraktit rakennekuvaukset Jonkin rakenteen dokumentoitu kuvaus (arkkitehtuurinäkymä, view) on usein abstrakti Tarkasteltavan asian kannalta epäoleelliset yksityiskohdat jätetään pois Jos kyse on suunnitelmasta, ei toteutuksen yksityiskohtia vielä voida tai edes haluta kiinnittää Tarkastelu tapahtuu yleensä järjestelmätasolla, jossa rakenneosat ovat vastuiltaan (toiminnot, tietosisältö) suhteellisen suuria (esim. asiakas palvelin - tietovarasto) Näkymät muodostavat usein hierarkian, jossa alemman tason näkymä tarkentaa jotain osaa ylemmän tason näkymästä 17 Abstraktit rakennekuvaukset Http server App Browser Application Data store Logger Client Server 18 9
Rakenteet ja ohjelmiston ominaisuudet Oleellista on, että rakenteiden ja niiden kuvausten perusteella voidaan tehdä päätelmiä jollekin sidosryhmälle tärkeistä ohjelmiston makrotason ominaisuuksista Tarkoituksenmukaisuus, luotettavuus, tehokkuus, helppokäyttöisyys, turvallisuus, muutettavuus, ulkoiset riippuvuudet, skaalautuvuus, Asiakas, loppukäyttäjä, kehittäjä, ylläpitäjä, liiketoiminnan johto, viranomainen, Ohjelmiston halutut ominaisuudet vaikuttavat siis siihen, mitä rakenteita arkkitehtuurissa tarkastellaan Ja kuinka tarkkoja tai yksityiskohtaisia kuvauksia tarvitaan Joskus yksityiskohdatkin voivat olla tärkeitä tiettyyn ominaisuuteen vaikuttavien suunnittelupäätösten ketjussa Arkkitehtuuri ei siis ole itsetarkoitus vaan väline 19 Arkkitehtuuri ja ohjelmiston elinkaari Robert C. Martin ( Uncle Bob ) 1 The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other. The purpose of that shape is to facilitate the development, deployment, operation, and maintenance of the software system contained within it. The ultimate goal is to minimize the lifetime cost of the system; and maximize programmer productivity. [1] Robert C. Martin.: Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall, 2017 20 10
II - Suunnittelupäätöksiä korostava määritelmä We propose to view a software architecture as a set of explicit architectural design decisions. In this perspective, the software architecture is the result of the architectural design decisions made over time 2 Ohjelmistoarkkitehtuuri koostuu joukosta eksplisiittisiä suunnittelupäätöksiä. Arkkitehtuuri on ajan myötä tehtyjen suunnittelupäätösten tulos. [2] Jansen, A., & Bosch, J. (2005). Software architecture as a set of architectural design decisions. In Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on (pp. 109-120). IEEE. 21 Arkkitehtuuritason suunnittelupäätös? All architecture is design, but not all design is architecture 3 The low level details and the high level structure are all part of the same whole. They form a continuous fabric that defines the shape of the system. 1 Tunnusmerkkejä Päätös koskee järjestelmätason asioita ja vaikuttaa pääasiassa muiden vaatimusten kuin järjestelmän tarjoamia palveluja tai toimintoja koskevien vaatimusten toteutumiseen Voi osoittautua kalliiksi, jos menee pieleen Tasapainottelee eri suuntiin vetävien voimien välillä Ohjaa ja/tai rajoittaa muita suunnittelupäätöksiä [3] Grady Booch, 2006 https://www.ibm.com/developerworks/community/blogs/gradybooch/entry/on_design 22 11
Esimerkki - Rackspace Hosted E-mail service provider Log.txt! 23 Tutkittava järjestelmä Sähköpostipalvelimien tuottamien lokitietojen tallennus ja käsittely asiakastukea varten Tehtävä (missio) Asiakkaan sähköpostin toimintaa koskevien ongelmien selvittämisen tukeminen sähköpostipalvelimien tuottamien lokitietojen perusteella Tarjottava ajantasaista tietoa riittävän pitkältä ajanjaksolta Kolme järjestelmäversiota, kolme erilaista arkkitehtuuria 24 12
V. 1 S-postipalvelinten paikalliset lokitiedostot Teknisen tuen pitää pyytää operaattoria ottamaan yhteys asiakkaan postipalvelimeen ja tutkimaan sen paikallista lokia ongelmien selvittämiseksi Rackspace toteutti skriptin, joka automaattisesti ottaa yhteyden joukkoon palvelimia ja suorittaa haun (grep) halutuntyyppisen palvelimen lokista; operaattorit voivat muokata hakuehtoja Ongelmia: Palvelinten, asiakkaiden ja tukipyyntöjen määrän kasvaessa yhä useammin suoritettavat haut alkoivat vaikuttaa haitallisesti palvelinten suorituskykyyn Hakujen tekemiseen tarvittiin aina operaattoria, mikä vei jatkuvasti kasvavan osan heidän työajastaan 25 V. 2 Lokitietojen keskittäminen yhteen tietokantaan S-postipalvelimet lähettävät muutaman minuutin väliajoin lokitietonsa ladattavaksi samaan relaatiotietokantaan tk-palvelimelle Teknikoilla on suora web-yhteys tietokantapalvelimelle ennalta ohjelmoitujen hakujen suorittamista varten Yksittäisten palvelimien lähettämät päivitykset kootaan yhteen säännöllisesti suoritettavaksi massapäivitykseksi (suoritetaan 10 min. välein) tietokantapalvelimen suorituskyvyn ylläpitämiseksi Ongelmia: Datan ja kyselyiden määrän jatkuvasti kasvaessa tietokantapalvelimen suorituskyky ja kapasiteetti muodostuivat pullonkaulaksi, häiriöt lisääntyivät Haut hidastuivat ja dataa hävisi välillä, vain muutaman päivän edestä lokitietoja kyettiin säilyttämään, varmuuskopioita ei ollut 26 13
V. 3 Lokitiedostojen rinnakkainen indeksointi hajautetussa tiedostojärjestelmässä S-postipavelimet syöttävät lokitiedostonsa usealle yksinkertaiselle palvelimelle (cluster) hajautettuun tiedostojärjestelmään (Hadoop DFS) Hadoop map-reduce operaatio indeksoi lokitiedostot ja muodostaa kaiken kattavan indeksin 15 min. välein Teknikoilla on web-liittymä hakujen tekemiseen kuten ennenkin Hakujen suoritus indeksistä on nopeaa, uudenlaisen haun ohjelmointi ja suoritus kestää kuitenkin joitain tunteja Täydellinen varmuuskopiointi, lokitietojen säilytys 6 kk:n ajalta 27 Ratkaisujen vertailua minaisuus V. 1 V. 2 V. 3 Toiminnallisuus Skaalautuvuus datan ja hakujen määrä Viive lokitietojen saanti s-palvelimilta Joustavuus uudet haut heikko välttävä hyvä välitön 10 min. 15 min. hyvä hyvä tyydyttävä 28 14
Huomioita 1 Järjestelmän tekniselle tuelle näkyvät toiminnot ovat käytännössä samat kaikissa versioissa Tukihenkilö sai kaikissa tapauksissa tarvitsemansa (samat) tiedot lokeihin kirjautuneista tapahtumista Järjestelmän toiminnallisuus (mitä järjestelmä tekee) ei siis ohjannut teknisiä ratkaisuja 1. versioonkin olisi voinut toteuttaa web-liittymän hakujen pyytämiseen operaattoreilta 29 Huomioita 2 Esimerkkijärjestelmän arkkitehtuuriin vaikuttavat eniten vaaditut laatuominaisuudet (quality attributes, -ilities, non-functional requirements ) Skaalautuvuus, tiedonsaannin viive, joustavuus uusien hakujen määrittelyssä Ylivoimaisesti tärkein järjestelmän ominaisuus on skaalautuvuus datan ja hakujen määrän suhteen Huonosti skaalautuva järjestelmä ei lainkaan kykene täyttämään tehtäväänsä toiminnan laajentuessa 30 15
Huomioita 3 minaisuus V. 1 V. 2 V. 3 Toiminnallisuus Skaalautuvuus datan ja hakujen määrä Viive lokitietojen saanti s-palvelimilta Joustavuus uudet haut heikko välttävä hyvä välitön 10 min. 15 min. hyvä hyvä tyydyttävä 31 Huomioita 3 Skaalautuvuuden parantuessa versiosta toiseen muut ominaisuudet hieman kärsivät Viive kasvaa (lokidatan tilannekuvan ikä) -> 15 min Joustavuus vähenee, koska uusien hakujen lisääminen vaatii enemmän työtä Joistakin vaadituista ominaisuuksista täytyy tinkiä toisten, tärkeämpien, hyväksi (trade off) Laatuominaisuuksien priorisointi esimerkissä: Skaalautuvuus > Viive > Joustavuus 32 16
entäs se arkkitehtuuri? Esimerkin järjestelmäversioiden kuvausten yhteydessä mainitut tekniset ratkaisut, eli suunnittelupäätökset, määrittävät järjestelmän arkkitehtuurin Ohjelmistoarkkitehtuuriin kuuluvat siis ne ohjelmiston suunnittelupäätökset, jotka merkittävästi vaikuttavat ohjelmiston laadullisten ominaisuuksien saavuttamiseen Suunnittelupäätösten pohjalta voidaan rakentaa järjestelmä, jolla on halutut ominaisuudet Sovellusalue ja kunkin sovelluksen/järjestelmän vaatimukset vaikuttavat siihen, mitkä tekniset seikat milloinkin nousevat arkkitehtuuriasioiksi ja mitä rakenteita on syytä tarkastella 33 Tyypillisiä arkkitehtuuripäätöksiä Järjestelmän jakaminen osiin (moduulit, komponentit) ja niiden roolien, toimintojen ja keskinäisten riippuvuuksien määrittely J:n rajapintojen (käyttöliittymät, ohjelmalliset ulkoiset rajapinnat, sisäiset rajapinnat) tunnistaminen ja erottaminen niiden kautta käytettävien toimintojen sisäisestä toteutuksesta J:n kehitystä ja ylläpitoa tukevat ratkaisut Eri syistä ja eri tahtiin muuttuvien osien erottaminen toisistaan Järjestelmällinen uudelleenkäyttö, tuoterungon käyttö, komponenttien vaihdettavuus ja siirrettävyys, diagnostiikka, testattavuus J:n ajoaikaiseen suorituskykyyn, skaalautuvuuteen, saatavuuteen, resurssien käyttöön ja turvallisuuteen vaikuttavat ratkaisut Palvelimet, prosessit ja säikeet, tieto- ja tapahtumavirrat, etäyhteydet, valvonta, tunnistaminen, sijoittelu laitteistoon, osien välinen viestintä J:n käsittelemän ja säilyttämän datan tallennus- ja saantiratkaisut * Jonkin teknologia-alustan tai framework:n (kehyksen) käyttö * (*) Uncle Bobin mielestä nämä ovat detaljeja, eivät arkkitehtuuria 34 17
Ohjelmistoarkkitehtuuri vs. Arkkitehtuuri? Suomen arkkitehtiliiton puheenjohtaja Huippuarkkitehtuuri on taidemuoto, jossa Erkki Rautio Tietoviikon haastattelussa rakennusten käyttäjien tarpeet usein 29.4.2012: Ei se herätä suuttumusta, jäävät vähemmälle huomiolle kuin vaan ehkä enemmänkin sääliä, kun itammattilaisilla ei ole omia taiteelliset näkökohdat ammattinimikkeitä. Venustas (!), Firmitas(?), Utilitas (??) 35 36 18
OHJELMISTOARKKITEHTUURIN HYÖDYT JA KÄYTTÖ 37 Arkkitehtuurin ilmeneminen Arkkitehtuuri on siis (1) valikoitu joukko ohjelmistoelementtien ja niiden välisten suhteiden muodostamia rakenteita tai (2) joukko näitä koskevia suunnittelupäätöksiä Konkreettisesti nämä rakenteet / päätökset voivat ilmetä Ideoina ja periaatteina (kehittäjien mielessä) Konkreettisina rajoitteina (suunnittelulle ja toteutukselle) Dokumentteina (muodollisina tai vapaamuotoisina) Malleina (UML, formaalit mallinnuskielet) Koodina (kirjastot, kehykset, alustat, esimerkit ja prototyypit, lähdekoodin struktuuri ja riippuvuudet, paketointi ja nimentä) ja suoritusaikaisina objekteina Implementaation ilmentämä arkkitehtuuri on tietysti lopullinen totuus (ei välttämättä vastaa dokumentoituja suunnitelmia!) 38 19
Arkkitehtuurin käyttö Arkkitehtuurin käyttötavat ohjelmistokehityksessä voidaan jakaa karkeasti kahteen kategoriaan Preskriptiivinen eli ohjaava käyttö Deskriptiivinen eli kuvaileva käyttö 39 Ohjaava käyttö Arkkitehtuuri määrittää järjestelmän perusrakenteen Analogiana eläimen luuranko Arkkitehtuurin lähtökohdaksi voidaan valita tyyli (architectural style) tai patterni (architectural pattern), joka kiinnittää elementtien typpit/vastuut/roolit ja niiden välisten liitosten ja yhteyksien ominaisuudet Ei voida sanoa, onko jokin tyyli absoluuttisesti parempi kuin toinen, vaan täytyy arvioida tyylin sopivuutta kehitettävän ohjelmiston tarpeisiin nähden 40 20
Ohjaava käyttö Arkkitehtuuri vaikuttaa laatuominaisuuksiin Arkkitehtuuri mahdollistaa haluttujen ominaisuuksien saavuttamisen Sopimaton arkkitehtuuri voi myös estää sen Arkkitehtuuri on (enimmäkseen) riippumaton toiminnallisuudesta Saman toiminnallisuuden voi toteuttaa melkein minkälaisella arkkitehtuurilla tahansa Mutta: huonosti valittu arkkitehtuuri voi tehdä toiminnallisuuden toteuttamisen vaikeaksi ja kalliiksi (joskus jopa mahdottomaksi)!! 41 Ohjaava käyttö Arkkitehtuuri ohjaa toteutusta rajoitteiden avulla (guide rails) Esimerkiksi halutaan suoraan kieltää käytettävyyden tai tietoturvallisuuden vuoksi huonoiksi tiedetyt ratkaisut Annetaan malli, jonka mukaan toteutetaan tietyt asiat (tai tarjotaan laatuvipu, kts. seuraava osio) Rajoitteet auttavat kehittäjiä monin tavoin Kokemuksen siirto tiivistetyssä muodossa asiantuntijoilta, jotka ovat perustelluista syistä asettaneet rajoitteet Käsitteellisen eheyden (conceptual integrity * ) vahvistaminen ja kompleksisuuden vähentäminen tarpeetonta luovuutta rajoittamalla Koodin ajonaikaisen käyttäytymisen helpompi ymmärtäminen (*) A single good idea consistently applied is better than several brilliant ideas scattered across a system (Fred Brooks) 42 21
Kuvaileva käyttö Ohjelmiston ja suunnitteluratkaisujen ymmärtäminen Abstrahointi yksityiskohtia pois suodattamalla Sopivasti valitut rakenteet ja niitä tietystä näkökulmasta esittävät näkymät (view) ovat erinomaisia ymmärryksen lähteitä Uudet kehittäjät, johto, asiakkaat, alihankkijat, jne.! Liiketoiminnallisten tavoitteiden toteutumisen seuraaminen Tuoteperheet, COTS-komponenttien käyttö, integrointi ulkoisiin palveluihin, standardointi, lisensointi jne. 43 Kuvaileva käyttö Rajoitteiden noudattamisen valvonta Esimerkiksi näkymän muodostaminen rakenneosien (komponenttien, kerrosten) välisistä riippuvuuksista, jolloin voidaan havaita arkkitehtuurin rajoitteiden kieltämät riippuvuudet Esim. kerrosarkkitehtuurissa alemman kerroksen komponentti kutsuu ylemmän kerroksen palvelua muuten kuin palvelun asettaman! takaisinkutsurajapinnan kautta, riippuvuussyklien kieltäminen Organisaation kehittäminen Vahvasti toisiinsa kytkeytyvien elementtien kehittämisvastuun jako kannattaa miettiä tarkkaan kommunikaatio-ongelmien välttämiseksi Conwayn laki organisaatio kehittää rakenteeltaan itsensä näköisiä arkkitehtuureja 44 22
Muita hyötyjä Riskien hallinta Arkkitehtuurityö kannattaa keskittää tunnistettujen riskien eliminoimiseen tai lieventämiseen Kiinnitetään jatkuvaa huomiota tärkeimpiin teknisiin uhkiin Vaatimusten täsmentäminen Vaadittujen laatuominaisuuksien analysointi ja arkkitehtuurin suunnittelu niiden saavuttamiseksi auttaa huomaamaan ristiriitaisuuksia ja epätäsmällisyyksiä vaatimuksissa ja määrittelyissä Arkkitehtuurin suunnitteluun liittyvä laatuominaisuuksien tasapainottelu (trade off) pakottaa priorisoimaan laatuvaatimukset 45 KUINKA PALJON ARKKITEHTUURIA? 46 23
Kaikilla ohjelmistoilla on arkkitehtuuri Arkkitehtuuriset suunnittelupäätökset syntyvät jossain ohjelmistokehitysprojektin aikana - tehtiin ne tietoisesti tai ei Arkkitehtuuriratkaisut ovat periaatteessa tärkeitä projektien ja ohjelmistojen onnistumisen kannalta, mutta käytännöissä on paljon vaihtelua Kurssikirjassa George Fairbanks tunnistaa kolme eri lähestymistapaa arkkitehtuurin suunnitteluun ja käyttöön 47 Tapa 1: Arkkitehtuuri on yhdentekevää (indifferent) Monissa projekteissa ei arkkitehtuurityötä juuri tehdä eikä arkkitehtuuria erikseen suunnitella (edes uuskehityksessä) Syitä Tietämättömyys mennään tuurilla Pieni projekti ja/tai pienet riskit - mikä vaan todennäköisesti toimii Oletusarkkitehtuurin käyttö (presumptive architecture) 48 24
Oletusarkkitehtuurit Monilla toimialoilla on järjestelmä- ja ohjelmistotoimittajia, jotka ovat vakiinnuttaneet omat teknologiansa ja arkkitehtuuriratkaisunsa alan standardeiksi (de facto) Vanha viidakon sanonta: nobody ever got fired for buying IBM Tarjolla on ohjelmistokehyksiä 4 ja alustoja, jotka Tarjoavat perusoiminnallisuuden valmiina uudelleenkäytettävinä komponentteina/kehyksinä/kirjastoina Kiinnittävät monet laatuominaisuudet (tai asettavat rajoituksia) Turvallisuus, suorituskyky, ylläpidettävyys, Pyrkivät vapauttamaan sovelluskehittäjän keskittymään sovelluskohtaisen toiminnallisuuden toteuttamiseen Toiminnanohjaus, asiakkuuksien hallinta, web-palvelut, e-commerce, mobiiliapplikaatiot jne jne. [4] https://en.wikipedia.org/wiki/software_framework 49 Oletusarkkitehtuuri Projektin ainoaksi arkkitehtuuriratkaisuksi jää käytettävän ohjelmistokehyksen valinta, missä arkkitehtuuriasioita enemmän saattavat painaa muut seikat Yhteensopivuus, käyttöympäristö, palvelinympäristö, henkilöstön osaaminen, ohjelmointikieli, markkinatilanne, lisenssi- ja tukiehdot, jne. Riskejä Arkkitehtuurin rapautuminen ajan myötä oman arkkitehtuurisuunnittelun ohjaavan vaikutuksen ja yhteisen arkkitehtuurinäkemyksen puuttuessa Monimutkaisuus, joka kehysten ja alustojen (projektin kannalta turhien) piirteiden myötä tulee ratkaisuun mukaan 50 25
Oletusarkkitehtuuri Referenssiarkkitehtuuri Esimerkinomainen ratkaisu tietyn tyyppisten järjestelmien (tai niiden osien) arkkitehtuurille Kuvaa arkkitehtuuriratkaisun spesifikaation muodossa (vrt. ehdotus standardiksi) Voi olla sovellusaluekohtainen tai yrityskohtainen Referenssiarkkitehtuurin määrittelijä toivoo usein, että siitä tulisi vallitseva oletusarkkitehtuuri 51 Tapa 2: Arkkitehtuurikeskeinen (focused) Tunnusmerkkeinä ovat tietoinen arkkitehtuurin valinta ja suunnittelu laatuvaatimusten ymmärtämisen pohjalta Arkkitehtuuri ei toisaalta saisi vaikeuttaa toiminnallisten vaatimusten toteuttamista Pyritään aktiivisesti tunnistamaan vaatimukset, jotka vaikuttavat arkkitehtuuriratkaisuihin Vaatimusten kriittinen tarkastelu ja rivien välistä lukeminen (implikaatiot) 52 26
Arkkitehtuurikeskeinen (focused) Ongelmanratkaisun ja päätelmien apuna käytetään usein abstraktioita ja arkkitehtuurinäkymiä Järjestelmän komponenttien ja niiden liitäntöjen tarkastelu Moduulien väliset riippuvuudet, kommunikoivat prosessit, pääkäyttötapausten kulku, Ei vaadi lähtökohtaisesti minkään tietyn ohjelmistokehityksen prosessimallin noudattamista eikä täydellistä dokumentointia 53 Tapa 3: Arkkitehtuuri laatuvipuna (hoisting * ) Tehdään tietoinen arkkitehtuuripäätös jonkin tietyn ominaisuuden halutun tason (laatuvaatimuksen) saavuttamiseksi (suorituskyky, siirrettävyys, testattavuus ) Kehittäjien ei tarvitse eivätkä he saa keksiä omia ratkaisujaan Ratkaisu voidaan esimerkiksi implementoida koodiksi ja tuoda suoraan kehittäjien käyttöön Koodikirjastona, komponentteina, tai konkreettisena automaattisesti valvottuna rajoitteena Yleistä ohjelmistokehyksissä (framework) Valmiin koodin käyttö takaa halutut ominaisuudet ilman että kehittäjien tarvitsee erikseen tehdä mitään Esim. resurssien, rinnakkaisuuden tai transaktioiden hallinta Suhteellisen pienellä määrällä työtä (uudelleenkäytettävä koodi) saadaan suuri vipuvaikutus järjestelmän laatuominaisuuksiin (leverage, hoisting) (*) hoist: (v) nostaa, (s) nostolaite, talja 54 27
Laatuvipu Vivun käyttöön liittyy usein harkintaa laatuominaisuuksien tasapainottelun kannalta (trade offs) Vipua on yleensä pakko käyttää, joten vivutetun ominaisuuden on syytä olla riittävän tärkeä Vivutus vai kehittäjän hivutus? Jotakuta rajoitukset voivat haitata, mutta toisaalta ne vapauttavat kehittäjän aikaa ja energiaa muihin asioihin kaikki eivät ole eksperttejä hankalien laatuominaisuuksien alueella (esim. transaktioiden ja rinnakkaisuuden hallinta) 55 Esimerkkejä Java EE Application Model https://docs.oracle.com/javaee/7/tutorial/overvie w002.htm#bnaax 56 28
Esimerkkejä Tavoiteltu ominaisuus: älypuhelimessa taustalla olevien sovellusten huomaamaton sulkeminen ja niiden tilan automaattinen palauttaminen käyttäjän tuodessa sovelluksen taas esiin muistin vapautus, akun latauksen säästö, käyttökokemus eli aidon moniajon simulointi Arkkitehtuuriratkaisu (Android/WindowsPhone): KJ:n sovellusarkkitehtuuri tarjoaa laajennospisteet, joihin sovelluskohtainen tilatiedon tallennus- ja palautuslogiikka (save/restore) koodataan Kehittäjä koodaa (takaisinkutsumetodina/ tapahtumankäsittelijänä) sovelluksen tilan kirjoittamisen ja lukemisen KJ:n tarjoamaan tietovarastoon KJ (sovellusarkkitehtuuri) käynnistää tilan tallennuksen ja lukemisen (eli kutsuu kehittäjän koodia) automaattisesti tilanteen mukaan Käyttäjälle sovellus näyttäytyy jatkuvasti päällä olevana, mutta sen käyttämät järjestelmäresurssit voidaan kuitenkin välillä vapauttaa muuhun käyttöön Monimutkaistaa hieman sovelluskehitystä 57 Esimerkkejä Tavoiteltu ominaisuus: ladatun energian säästö akkukäyttöisessä mobiililaitteessa Arkkitehtuuriratkaisu (Symbian OS): Applikaatioiden ja yleisten palveluiden (esim. tiedosto-operaatiot) toteuttaminen tapahtumankäsittelijöinä (asiakas-palvelin tyyli) Applikaatio- ja palvelusäikeet (thread) toimivat vain reagoidessaan tapahtumiin (kälitapahtuma, palvelupyyntö), muuten ne odottavat passiivisina (wait) Kaikki kommunikointi tapahtuu asynkronista viestinvälitystä käyttäen (palvelupyyntö-vastaus -parit) Kaikki keskeiset KJ:n palvelut on toteutettu palvelinsäikeinä Käyttöjärjestelmän on helppo todeta milloin kaikki säikeet vain odottavat tapahtumia, jolloin prosessori (CPU) voidaan ajaa virransäästötilaan (sleep mode) -> energiansäästö, parempi akun kesto 58 29
Millaisissa projekteissa arkkitehtuurityö on erityisen tärkeää? Pieni ratkaisuavaruus (solution space) Toimivia ratkaisuja on vähän ja sellaisen löytäminen on vaikeaa Todennäköisyys, että mikä vain arkkitehtuuri toimii, on siis pieni Ohjelmistohäiriöiden (failure) vakavat seuraukset Vahingot ihmisille, ympäristölle ja omaisuudelle Vaikeat laatuvaatimukset Skaalautuvuus, ylivertainen käyttökokemus 59 Millaisissa projekteissa arkkitehtuurityö on erityisen tärkeää? Uusi sovellusalue (domain) Uudet käsitteet, toiminnot, vaatimukset, teknologiat jne. Ei ole tuttua kaavaa tai rakennetta (conceptual model), jonka pohjalta lähteä rakentamaan ratkaisuja Tuoteperheet (tavoitteellinen uudelleenkäyttö) Yhteisen tuoterungon tai komponenttikirjaston luominen monia eri tuotteita varten, joissa on kuitenkin paljon samaa toiminnallisuutta Pyritään tunnistamaan yhteiset, eri tuotteissa tarvittavat komponentit ja implementoimaan ne vain kerran Pyritään uudelleenkäyttämään mahdollisimman pitkälle myös samaa arkkitehtuuria eri tuotteissa (suunnittelutyön uudelleenkäyttö) 60 30
Millaisissa projekteissa arkkitehtuurityö on erityisen tärkeää? Tee ajatuskoe - mieti, mitä seurauksia väärillä arkkitehtuuriratkaisuilla voisi olla: mikä voi mennä vikaan? Jos merkittäviä riskejä ei ole, arkkitehtuurin miettimiseen ei kannata käyttää paljonkaan aikaa 61 G. Fairbanks: Risk-driven approach Idea: Arkkitehtuurisuunnittelua tehdään vain sen verran kuin projektiin liittyvien riskien hallitseminen vaatii Riskit voivat liittyä ohjelmiston käyttöön ja sen laatuominaisuuksiin (tuoteriski) Korkea suorituskyky, turvallisuus, skaalautuvuus, uhka ihmisille ja omaisuudelle, tai sen kehitykseen (projektiriski) teknologiat, henkilöstön määrä ja osaaminen, asiakas, aikataulu, työkalut, Kysytään: Mikä voi mennä pieleen ohjelmistoa käytettäessä ja kehitettäessä? Ja mietitään, voiko arkkitehtuuriratkaisuilla pieleen menon todennäköisyyttä pienentää tai sen seurauksia lieventää minkä jälkeen voidaan suunnata arkkitehtuurityö asioihin, jotka ovat oikeasti tärkeitä 62 31
LOPUKSI 63 Kuningas näkee pelin toisin http://img.yle.fi/urheilu/jalkapallo/article6978622.ece/alternates/w580/studiokuva%20litmanen%20kuusela.jpg 64 32
Kurssin pääoppimistavoitteet Tietää mitä ohjelmistoarkkitehtuuri on ja mihin sitä käytetään Tuntee ja osaa käyttää joitakin keskeisiä suunnitteluperiaatteita sekä arkkitehtuurityylejä ja patterneja ohjelmiston arkkitehtuurin suunnitteluun Tietää miksi ja milloin arkkitehtuurimalleja laaditaan ja osaa muodostaa kanonisen rakenteen mukaisia näkymiä arkkitehtuuriin Ymmärtää arkkitehtuurin arvioinnin ja ohjelmistokehysten (framework) suunnittelun perusideat (syvennetään harjoitustyössä) 65 The Road goes ever on and on Sten Porse, license: CC-BY 3.0 66 33