Ohjelmistoarkkitehtuurit Refaktorointia, ohjelmien ylläpitoa ja evoluutiota. Kevät 2016

Transkriptio

1 Ohjelmistoarkkitehtuurit Refaktorointia, ohjelmien ylläpitoa ja evoluutiota Kevät 2016 Samuel Lahtinen Ohjelmistoarkkitehtuurit

2 Aiheita Refaktorointi (N4S-projekti, ~15 firmaa) Määritystä, esimerkkejä Pienempi vai suurempi? Refaktorointi ja ohjelmistotyö Ohjelmien ylläpitoa ja evoluutiota Perinnekoodit (legacy) Yritystietojärjestelmistä pikaisesti

3 Mitä on refaktorointi?

4 Mitä on refaktorointi? Ohjelman rakenteen muuttamista ilman että toiminnallisuus muuttuu is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Martin Fowler Its heart is a series of small behavior preserving transformations. Each transformation (called a refactoring ) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

5 Mitä erilaisia refaktorointitoimia on?

6 Mitä erilaisia refaktorointitoimia on? Karkea jako pienet jokapäiväisen työn lomassa tehtävät ylläpito- ja siivoustoimet Funktiotason siivoilut Pilkkominen, yhdistely, selkeyttäminen, parametrit, delegoinnit/niiden poisto Isommat refaktoroinnit, vaatii selkeän päätöksen refaktoroinnista Isompi operaatio koostuu sarjasta pieniä (no shit!?!) Ei tehtävissä normaalin ominaisuuksien tekemisen/bugikorjauksien ohessa Refactoring or redesign? (termistömasturbaattoreille)

7 Refaktorointi ja työkalut IDE:t, modernit koodieditorit (refaktorointitoimien tuki, uudelleennimeäminen, funktion parametrien muutokset) Erilaiset lisätyökalut, esim.

8 Esimerkkejä refaktorointitoimenpiteistä class CircleArea { const double PI = ; double CalculatePaintNeeded( double paintperunit,double radius ) { } double area = PI * radius * radius; return area / paintperunit; } bool paintarea( double paintamount, Color paintcolor ) {... } Extract method class CircleArea { public const double PI = ; private double radius; } CircleArea(... ){} double CalculatePaintNeeded( double paintperunit ) { return area() / paintperunit; } double area() { return PI * radius*radius; } bool paintarea( double paintamount, Color paintcolor ) {... } void setradius( double newradius );

9 Esimerkkejä refaktorointitoimenpiteistä Replace Parameter with Explicit Methods void SetValue(string name, int value) { if (name.equals("height")) { height = value; return; } if (name.equals("width")) { width = value; return; } Assert.Fail(); } void SetHeight(int arg) { height = arg; } void SetWidth(int arg) { width = arg; } Koodin luettavuus paranee asetamoottorintila( kaynnissa, true ); kaynnistamoottori();

10 Esimerkkejä refaktorointitoimenpiteistä Hierarkian litistäminen (collapse hierarchy) Kantaluokan lisääminen (extract superclass)

11 Esimerkkejä refaktorointitoimenpiteistä Korvataan saman asian eri tietotyypeille tekevät funktiot / tai luokkahierarkia Template-funktiolla (tai luokalla)

12 Näitähän riittää eivät mitään rakettitiedettä, vaan peruskoodausjuttuja Kuitenkin hyödyllisiä vilkaista, sisältää paljon hyvän koodin periaatteita Lisää esimerkkejä:

13 Esimerkkejä isommista refaktoroinneista Luokka turvonnut ajansaatossa, ahminut vastuualueita palastelu osiin, aloitettiin vaiheittain, luotiin rajapinnat roolien mukaan, sama toteuttaja, testit rajapintojen suhteen, luotiin uusi toteutus Palvelusta tullut huomattavasti ennakoitua suositumpi ja samalla suorituskykytarpeet kasvaneet, nykyinen toteutus skaalautuu huonosti Jaetaan sovellus useampaan mikropalveluun, helpompi antaa suorituskykyä sitä eniten tarvitsevalle osalle, joka vaatii eniten suorituskykyä. Toteutustyö ja pilkkominen tehdään rinnalla, kun vanha toteutusversio käynnissä

14 Esimerkkejä isommista refaktoroinneista Sovelluksen toteutuspuolen edetessä huomataan, että osa tiedoista erittäin hankalaa esittää käyttöliittymässä (tietojen sidonta valitulla tekniikalla haastavaa). Käyttöliittymä kirjoitetaan kokonaan alusta käyttäen uutta kehystä (.js framework vaihtuu) Laajasti kolmannen osapuolen käytössä olevan palvelun rajapintoja halutaan päivittää ja uudistaa. Tehdään uusi versio uudella nimellä vanhan rinnalle, pidetään vanha hengissä, kunnes kaikki käyttäjät on saatu siirtymään uuteen. (tässä auttaa reititys, seuranta, jne.) Vanhaan joudutaan tekemään pakolliset päivitykset niin pitkään kun sillä on käyttöä.

15 Miksi refaktoroida?

16 Miksi refaktoroida? Uusien ominaisuuksien lisääminen vaatii sitä Bugien korjaaminen vaatii myös refaktorointia Testattavuus, testien tekeminen vaikeaa tai mahdotonta Nopeutetaan tulevien ominaisuuksien toteuttamista Monimutkaisuuden/vaikeaselkoisuuden (complexity) vähentäminen Ylläpidettävyyden helpottaminen Oma/työkavereiden mielenterveys Refaktorointi voi olla mukavaa

17 Syitä refaktorointitarpeeseen Teknisen velan kertyminen Kiire toteuttaa ominaisuuksia Toteuttajat pihalla Alussa ei tiedetä riittävästi (puutteellinen tieto asiakkaalta, oma osaaminen ei vielä täydellistä jne.) Järjestelmän käyttötarkoitus voi muuttua sen elinaikana Järjestelmän vaatimukset muuttuvat, esimerkiksi suorituskyky, käyttäjämäärät jne. Kehittyminen ihmisenä ja koodarina, uusien asioiden oppiminen Legacy-järjestelmän ylläpitäminen

18 Jotain koodihajuista (code smells) Yleinen tunne, tää ei oo oikein kunnossa, tän katselu ja päivittäminen on ruotoista touhua Koodista suoraan, pitkiä metodeja/luokkia, duplikoitua koodia, vaikeaselkoisuus, todo-henkisiä kommentteja koodissa, vastuualueiden epäselvyys, uudet ominaisuudet vaativat muutoksia moneen paikkaan, jne. Muita merkkejä, kommentit versiohallinnassa, taskien venyminen

19 Vinkkejä 1. Turvaverkko kuntoon: versiohallinta ja automaattitestit lähes pakollisia 2. Käytä versiohallintaa refaktorointien kirjaamiseen. Tee ensin refaktorointi, sitten ominaisuuden lisääminen, molemmista commit. 3. Tarkista ja tarvittaessa päivitä testit ennen refaktoroinnin aloittamista 4. Koodikatselmoinnit käyttöön isompien refaktorointien kanssa 5. Hajota & korjaa: riko/poista koodi, jota olet uudelleenkirjoittamassa kunnolla ja kirjoita uudelleen, testaa uusi käyttäen testipatteria

20 Vinkkejä 1. Tee pieniä refaktorointitoimia aina kun näet tarvetta sellaiselle. Voit tehdä näitä bugikorjauksien ja ominaisuuksien lisäämisen kanssa samaan aikaan. Näin huollat koodia ja se ei happane vaan jopa paranee. 2. Liitä pikkurefaktorointi mukaan aika-arvioihin, niin pystyt siistimään koodia työn ohessa. 3. Ajoita isommat refaktoroinnit järkevästi: älä tee isoja refaktorointeja juuri ennen julkaisua. Jos käytössä CI & CD-putket, niin älä tee isoja refaktorointeja loppuviikosta tai kriittisten bugikorjausten kera. 4. Omista yksi päivä viikossa refaktoroinnille 5. Pyri saamaan asiakkaan puolelle tekniikoista ymmärtävä henkilö. Näin refaktorointitarpeet ovat helpompia kommunikoida. 6. Pienet tiimit samassa huoneessa, niin refaktorointi on helppoa. ( mää kirjoitan tän uusiks, älkää koskeko tähän pariin tuntiin ) Refactoring-a Shot in the Dark? IEEE Software Marko Leppanen Simo Makinen Samuel Lahtinen Outi Sievi-Korte Antti-Pekka Tuovinen Tomi Mannisto

21 Refaktorointipatterneja?

22 Refaktorointi on turhaa? ei kovinkaan häävisti tehty tutkimus, mutta saanut julkisuutta Metriikat vs. refaktorointi (hatusta repäistyt metriikat) opiskelijat refaktoroimassa (itselleen outoa koodia, koodin koko 4500 riviä) Lisätään olioita, testataan onko koodi tehokkaampaa

23 Metriikat? Metriikat eivät välttämättä anna mitään sellaista tietoa joka ei olisi jo selvillä järkevälle ja kokeneelle kehittäjälle Tutkimuksessa vain yhdessä paikassa käytössä & hyödylliseksi koettu Ei kuitenkaan tyrmätty, todettiin että koodarin ja metriikan kertomat ongelmakohdat samoja Metriikoista voi olla haittaa, voi ohjata vain muuttamaan asioita jotka näkyvät metriikoiden avulla Koodirivit (LOC/NonCommentinLOC), luokkien koko, ylläpidettävyysindeksit, syklomaattinen kompleksisuus (cyclomatic complexity), perintähierarkioiden syvyys, jäsenmuuttujien määrä, parameterien määrä, funktioiden määrä Hyödyllisin metriikoista LOC (kun mietitään projektin kompleksisuutta Metriikoiden käyttö ja refaktorointitarpeen myyminen johdon suuntaan

24 Historiaa opetuskursseilta C++:n tyylianalysaattori Style++ oli käytössä kursseilla Automaattisesti tarkastetut työt (merkkijonovertailua tuloksille) Tyylianalysaattori ja minimipistemäärä, jolla palautus menee tarkastettavaksi Tutki mm. (kopio)rakentajien, alustuslistojen, funktioiden ja kooditiedostojen pituutta, sisennysten, muuttujien alustamisen, tyhjien rivien määrää jne. Sinällään järkeviä kohteita, mutta johti usein typeryyksiin tekemiseen

25 Työkaluja Refaktoroinnin aputyökalut, versiohallinta ja testiympäristöt Koodin muokkauspuolella editorit tarjoavat jonkin verran refaktorointitukea (uudelleen nimeämiset, parametrien muokkaaminen, funktioiden luonti koodipätkästä, osassa funktioiden siirtäminen luokkaan/pois luokasta) Metriikkatyökalut ennakkovaroittimena Metriikkatyökalut, esim. yleinen SonarQube ( )

26 Refaktorointipäätösten tekeminen Refaktoroinnin aputyökalut, versiohallinta ja testiympäristöt Koodin muokkauspuolella editorit tarjoavat jonkin verran refaktorointitukea (uudelleen nimeämiset, parametrien muokkaaminen, funktioiden luonti koodipätkästä, osassa funktioiden siirtäminen luokkaan/pois luokasta) Metriikkatyökalut ennakkovaroittimena Metriikkatyökalut, esim. yleinen SonarQube ( )

27 Refaktorointipäätösten tekeminen Decision-Making Framework for Refactoring, IEEE MTD 2015, Marko Leppänen Samuel Lahtinen Kati Kuusinen Simo Mäkinen Tomi Männistö Juha Itkonen Jesse Yli-Huumo Timo Lehtonen

28 Refaktorointi versiohallinnassa

29 Koodin rapautumisen estäminen Refaktoroinnilla, huolehditaan lähdekoodin ja rakenteen siisteydestä Koodin pitäminen siistinä Tyylisäännöt, ohjelmointikielen käyttösäännöt ja nimeämiskäytännöt: Esimerkiksi: Ohjelmalle sovittu korkean tason arkkitehtuuri, usein kokoelma sääntöjä siitä, miten asiat tehdään, missä saa tehdä mitäkin Ei rikota, tai ohjelmasta tulee nopeasti ylläpitokelvoton

30 Oheismateriaalia

31 Yhteenveto Perusrefaktorointi osa päivittäistä työtä Isompien toimien tekeminen vaatii yleensä suunnittelua (ja asiakkaan suostumuksenkin) Metriikoiden käyttö harvinaista Työkalutuki lähinnä koodieditorien perusrefaktorointitoiminnot, muuten refaktorointi vaatii omien aivojen käyttöä, vaikeaa keksiä järkevää työkalua tähän Versiohallinta, testiympäristöt, (CI, CD)

32 Perintönä saatua koodia (legacy code)

33 Miksi legacy-koodi on hankalaa? Ohjelmistoarkkitehtuurit

34 Miksi legacy-koodi on hankalaa? Ei testejä Järkevien testien tekeminen lähes mahdotonta Koodia vailla rakennetta Toteutustavat kummallisia Vanhat kääntäjät ja niiden kanssa tehdyt optimoinnit Vanhat kääntäjät ja niiden puuttellinen tuki kielen ominaisuuksille ja omat viritykset Ohjelmointityylit ja sopimukset puuttuvat Dokumentaatio puuttuu Arkkitehtuuria ei ole Ohjelmistoarkkitehtuurit

35 Legacyn kanssa puljaaminen Tunnista vaatimukset Pyri ymmärtämään koodia Muokkaa koodia Kirjoita testit (tämä voi olla myös toisena kohtana) Ohjelmistoarkkitehtuurit

36 Jotain vinkkejä Kääntäjän hyväksikäyttö Kääntäjä löytää projektista riippuvuuksia (esim. muuta nimeä jne tutki käännösvirheet) Funktioiden muodostaminen/metsästys Uusi rajapinta ja toteutus, jossa käytetään vanhaa Yksikkötestit uudelle rajapinnalle ja sen tarjoamalle toiminnallisuudelle Pariohjelmointi Ohjelmistoarkkitehtuurit

37 Ohjelmien ylläpito & evoluutio Ylläpito ja evoluutio voi olla refaktorointia, jos järjestelmänlähdekoodi saatavilla ja järkevästi muokattavissa Eritasoisia ylläpitotehtäviä / refaktorointia: Yksinkertaiset bugikorjaukset, lähdekoodi saatavilla, rajoittuvat muutettaviin koodilohkoihin (ehkä ) Testien saatavuus? Laajentaminen Mukauttaminen (vaihtuvat komponentit, osakokonaisuudet) Rakenteen uusiminen Ohjelmistoarkkitehtuurit

38 Ohjelmien ylläpidosta / muuntelusta Arkkitehtuuritason muutokset usein kalliita Yksittäisten toteutusosien muuntelu helpompaa Yhteistoiminta ja isommat muutokset Tarve ymmärtää ohjelman rakenne, arkkitehtuuri Muutostarpeita: Korjaukset, päivitykset Järjestelmän uudistaminen (pala palalta) Rautatason muutokset Ohjelmistoarkkitehtuurit

39 Muutoksen koon ja hinnan arviointia Yksi mahdollinen tapa selvittää: arkkitehtuuriarviointi, jossa keskitytään muutostarpeeseen ja päätösten selvittämiseen Hiljaisen tiedon dokumentointi + muutoksen suuruuden arviointi Toimii, jos mukana alkuperäisen järjestelmän suunnittelijoita/toteuttaneita Ohjelmistoarkkitehtuurit

40 Kurssilla opittuja työkaluja Muunneltavuuden hallinta ja ylläpito/päivitykset Päivitykset, muutokset helpompi Ei-suunnitellut muutokset, enemmän työtä/rakenteeseen koskemista esim. pattern-henkinen lähestymistapa: millä tämän ongelman saisi ratkaistua? Dokumentaatiota arkkitehtuuriratkaisuista, helpompi ymmärtää mitä ollaan tekemässä Tämä päätös on tehty näistä syistä ovatko edelleen valideja, mitä muita vaikutuksia muutoksesta seuraa? Ohjelmistoarkkitehtuurit

41 Käärimistä (wrapping) Kääriminen, rajapintojen uudistamista =Black-box re-engineering (riittää kun tietää mitä mokkula tekee, ei tarvi tietää toteutusta) Toteutusten tai tiedon/tietoesitysten kääriminen mukauttavaa ylläpitoa: käärittävien toimintojen ja tietoalkioiden tunnistamista Uudistava ylläpito: lähdetään rakentamaan järjestelmää uudestaan (toteutetaan järjestelmä uuden mallin mukaisesti) Ohjelmistoarkkitehtuurit

42 Käärintälähestymistapoja Hajoita ja hallitse (divide-and-conquer) vähittäinen uudistaminen rajapinnan tarjoaminen uudistettujen ja uudistamattomien osien välille Hajoita ja kääri (divide-and-wrap) kaikkien (uudistamattomien) osien kääriminen käärittyjen osien vähittäinen uudistaminen Yhdistä ja hallitse ohjelmistokehyksen rakentaminen uusien ja vanhojen osien välille kehys mallintaa järjestelmän sovellustoiminnallisuutta Ohjelmistoarkkitehtuurit

43 Toiminnallisuuden vaihto Ohjelmistoarkkitehtuurit

44 Uudelleenkäyttö Ohjelmistoarkkitehtuurit

45 Tehtävä Olet töissä Sköldpaddor ABB:ssä. Aikaisempi hittituote oli SSVN versiohallinta (komentoriviltä), mutta nyt ollaan siirtymässä kohti uusia tuulia. Komentorivin rinnalle luodaan myös graafinen maailma, jossa on helpompi tarkastella versiohallinan käyttöä ja tehdä vertailuja eri versioiden välillä. Vanhaan versiohallintaan halutaan pääsy myös uudessa graafisessa ympäristössä. Valitettavasti alkuperäisohjelma on toteutettu huumeiden vaikutuksen alaisena Cobolilla ja Perlin tanskalaisella murteella. Versiohallinta kyllä toimii moitteettomasti, mutta toteutuksen muuttaminen on mahdotonta. Minkälaisilla ratkaisuilla saisit hyödynnettyä vanhan komentorivihärpäkkeen toiminnallisuutta omassa toteutuksessasi? Ohjelmistoarkkitehtuurit

46 Yhteenvetoa Ylläpito ja evoluutio, pitkälti refaktorointia, mutta hieman eri näkökulmasta Usein legacy-järjestelmien tukemista tai niiden osien liittämistä uuteen järjestelmään Ohjelmistoarkkitehtuurit

47 Referenssejä, luettavaa Kirja: Working Effectively with Legacy Code, Michael Feathers Ohjelmistoarkkitehtuurit

48 Viestipohjaisten yritysjärjestelmien suunnittelumallit

49 Yritystietojärjestelmiä Erilaisia tapoja yhdistellä bisnes, kehitystyö, lopputuote ja toisaalta kuvata järjestelmän osia, kommunikaatiota Aholan vierailuluennon käsittelivät asiaa hyvin, täällä hieman samaa asiaa ja esimerkkejä suunnittelumalleista Yritystietojärjestelmät/muutokset niihin, joku tekee esim. business process management tyyppistä tutkailua Enterprise messaging systems, strukturoidut viestit, yhtenäiset protokollat, huomioalueita (turvallisuus, reititys, metadata, tilaajamalli, oikeudet (policy) viestisisältö ja otsikkotiedot eriytettyinä Ohjelmistoarkkitehtuurit

50 Yritystietojärjestelmiä Taustamateriaalia, perusperiaatteet valideja, uusimmat alustat/tekniikat puuttuvat esimerkeistä: Enterprise Integration Patterns: Patterns of Enterprise Application Architecture by (Martin Fowler with Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford) Mallintaminen jne. työkaluja ja mallinnustekniikoita tarjolla, esimerkki Enterprise systems architect: Ohjelmistoarkkitehtuurit

51 Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit: Viesti Kanava Reititys Muunnos Sovellus Sovellus Sovitin Sovitin Hallinta ja monitorointi (Hohpe & Woolf: Enterprise Integration Patterns. Addison-Wesley 2004) Ohjelmistoarkkitehtuurit

52 Esimerkki: Tilausten käsittely Asiakkaat Varasto Vaatimuksia: Jälleenmyyjä TKS Valmistajat Kuljetusliike - Asiakkaat voivat lähettää tilauksia webin kautta tai sähköpostiilla - Tilaus käsitellään monessa vaiheessa: varastotarkistus, toimitus, laskutus - Integrointi olemassaoleviin sovelluksiin: web-client, sähköpostiijärjestelmä, laskutus-, toimitus-, ja varastojärjestelmät Ohjelmistoarkkitehtuurit

53 Tilausten vastaanotto Viesti Kanava Reititys Muunnos Sovellus Sovellus Sovitin Sovitin Hallinta ja monitorointi Ohjelmistoarkkitehtuurit

54 Tilausten vastaanotto: useita lähteitä Web- GUI Viestiportti Kahdenvälinen kanava Viestimuuntaja Web -> Kanoninen sähköposti Kanavasovitin Julkaisija-tilaaja kanava Viestimuuntaja sähköposti-> Kanoninen Ohjelmistoarkkitehtuurit

55 Viestiportti (Messaging Gateway) Synkroninen, blokkaava: Sovellus Viestiportti Viestijärjestelmä - erottaa sovelluslogiikan viestinvälityksestä - tarjoaa sovellusaluekohtaisen API:n sovelluksen käyttöön - helposti vaihdettavissa - asynkroninen tapa: esim. sovellus jatkaa ja pollaa viestiportin tulosviestejä palvelupyyntö viestin lähetys tuloksen vastaanotto prosessointi Ohjelmistoarkkitehtuurit

56 Tilausten vastaanotto: useita lähteitä Web- GUI Viestiportti Kahdenvälinen kanava Viestimuuntaja Web -> Kanoninen sähköpostin vastaanottaja Kanavasovitin Julkaisija-tilaaja kanava Viestimuuntaja sähköposti-> Kanoninen Ohjelmistoarkkitehtuurit

57 Kanavasovitin (Channel Adapter) Löyhä sovitinliitos: Sovitin ei integroidu suoraan sovellukseen vaan välillisesti esim. - sovelluksen yleisen API:n kautta - tarkkailemalla sovelluksen aiheuttamia tapahtumia - tarkkailemalla sovelluksen tuottamia tiedostoja tai tietokantoja (esim. tietokantatriggeri) Ohjelmistoarkkitehtuurit

58 Tilausten vastaanotto: useita lähteitä Web- GUI Viestiportti Kahdenvälinen kanava Viestimuuntaja Web -> Kanoninen sähköpostin vastaanottaja Kanavasovitin Julkaisija-tilaaja kanava Viestimuuntaja sähköposti -> Kanoninen Ohjelmistoarkkitehtuurit

59 Kahdenvälinen kanava (Point-to-Point Channel) Voi olla useita potentiaalisia vastaanottajia, mutta kanava itse takaa, että vain yksi vastaanottaja saa kunkin viestin Mahdollisesta vastaanottajan valinnasta huolehtii kanava, vastaanottajien ei tarvitse koordinoida keskenään Ohjelmistoarkkitehtuurit

60 Tilausten vastaanotto: useita lähteitä Web- GUI Viestiportti Kahdenvälinen kanava Viestimuuntaja Web -> Kanoninen sähköpostin vastaanottaja Kanavasovitin Julkaisija-tilaaja kanava Viestimuuntaja sähköposti -> Kanoninen Ohjelmistoarkkitehtuurit

61 Kanoninen tietomalli (Canonical Data Model) tiedon esitys, joka on riippumaton sovelluksista sovellusriippuvat esitykset muunnetaan kanoniseen jos sovelluksen esitysmuoto muuttuu, riittää muuttaa muuntaja X kanoninen tai kanoninen X Ohjelmistoarkkitehtuurit

62 Viestimuuntaja (Message Translator) Muuttaa formaatin tai rakenteen muuttamatta informaatiota Erillinen komponentti Viestimaailman Sovitin (Adapter): muuttaa viestiformaatin XML-pohjaisten viestien muuntaminen keskenään: XSLT XML <-> jokin muu formaatti: XML jäsentäjät ym. Ohjelmistoarkkitehtuurit

63 Tilausten vastaanotto: useita lähteitä Web- GUI Viestiportti Kahdenvälinen kanava Viestimuuntaja Web -> Kanoninen sähköposti vastaanottaja Kanavasovitin Julkaisija-tilaaja kanava Viestimuuntaja sähköposti -> Kanoninen Ohjelmistoarkkitehtuurit

64 Julkaisija-tilaaja kanava (Publisher-Subscriber Channel) Viesti Tilaaja Julkaisija Julkaisijalta tuleva viesti kopioidaan kaikille tilaajille Kukin tilaaja saa jokaisen viestin kerran Tilaajat eivät tunne toisiaan eivätkä julkaisijaa Julkaisija ei tunne tilaajia Tarkkailija-suunnittelumallin idea viestimaailmassa (tapahtumaviestejä) Voi olla myös monta julkaisíjaa Tilaaja Tilaaja Ohjelmistoarkkitehtuurit

65 Kysyttävää?

66 Reititys Viesti Kanava Reititys Muunnos Sovellus Sovellus Sovitin Sovitin Hallinta ja monitorointi Ohjelmistoarkkitehtuurit

67 Tilausten käsittely tarkista varasto tarkista asiakas [OK] Poikkeusten käsittely toimita tavara lähetä lasku Ohjelmistoarkkitehtuurit

68 Tilausten käsittely Asiakashallinta Sisältöperustainen reititin kelvollinen tilaus Julkaisijatilaaja Julkaisijatilaaja Laskutus Toimitus Varastohallinta Yhdistäjä epäkelpo tilaus Ohjelmistoarkkitehtuurit

69 Yhdistäjä (Aggregator) Tilallinen komponentti Kerää koosteita sisääntulevista viesteistä Pitää yllä vaillinaisia koosteita Jos uusi viesti tekee jostakin vaillinaisesta koosteesta täydellisen, koosteviesti lähetetään eteenpäin Kooste ei ole välttämättä unioni (esim. valitaan paras tai ensimmäinen sopiva, muut unohdetaan) Ohjelmistoarkkitehtuurit

70 Tilausten käsittely Asiakashallinta Sisältöperustainen reititin kelvollinen tilaus Laskutus Varastohallinta Yhdistäjä Toimitus alihankkija/muu toimittaja epäkelpo tilaus Ohjelmistoarkkitehtuurit

71 Sisältöperustainen reititin (Content-based Router) Vastaanottaja/kanava määrätään viestin sisällön perusteella (esim. jonkin kentän arvo tai esiintyminen) Ongelma: reititin tuntee vastaanottajat ja riippuu niistä Mahdollinen ratkaisu: vastaanottajat informoivat (dynaamisesti) reititintä millaisia viestejä haluavat (Dynamic Router) Ohjelmistoarkkitehtuurit

72 Hallinta ja monitorointi Viesti Kanava Reititys Muunnos Sovellus Sovellus Sovitin Sovitin Hallinta ja monitorointi Ohjelmistoarkkitehtuurit

73 Älykäs Edustaja (Smart Proxy) Sovellus1 Pyyntö Vastaus1 Älykäs Edustaja Pyyntö Palvelun tarjoaja Sovellus2 Vastaus2 Vastaus Sovellukset lähettävät palvelupyyntöjä Smart Proxy toimii palvelun pyytäjien ja tarjoajan välissä SP pitää kirjaa pyytäjistä ja ohjaa vastauksen oikealle sovellukselle (Correlation Identifier antaa tunnisteen pyynnölle) SP voi kerätä metatietoa viesteistä (esim. käsittelyaika) ja lähettää sen valvontayksikölle Kontrolli Metatieto Ohjelmistoarkkitehtuurit

74 Yhteenveto Erillisiä osajärjestelmiä, niiden integrointia Tiedon välitys, tiedon käsittely ja vaiheet olennaisia Missä muodossa tietoa käsitellään, tietomalli? Ohjelmistoarkkitehtuurit

75 Ekosysteemijuttuja

76 Mikä ekosysteemi? Ohjelmistoalusta ja yhteisö, joka tuottaa sovelluksia alustalle Laajentavat alustaa, tekevät alustalla toimivia sovelluksia, voivat olla avoimia/suljettuja Alunperin käyttöjärjestelmä ja sen palvelut Siihen päälle ajureita, apupalveluita Sovelluksia, niitä hyödyntäviä muita sovelluksia jne. Ei tehdä enää pelkästään oman firman sisällä, laajentuminen organisaation ulkopuolelle mukana sosiaalinen ekosysteemipuoli (community) From Software Product Lines to Software Ecosystems LC09-SoftwareEcosystems-Accepted.pdf Ohjelmistoarkkitehtuurit

77 Määritelmää David G. Messerschmitt and Clemens Szyperski (Software ecosystems kirja): A set of businesses functioning as a unit and interacting with a shared market for software and services, together with relationships among them. These relationships are frequently underpinned by a common technological platform and operate through the exchange of information, resources, and artifacts. Lungu : A collection of systems, which are developed and co-evolve in the same environment (company/social/technical) Jan Bosch: Software ecosystems take various forms but typically consist of a company providing a software platform and a community of external developers providing functionality that extends the basic platform. Ohjelmistoarkkitehtuurit

78 Ekosysteemiajatelma, muutakin kuin käyttöjärjestelmätaso Ekosysteemiajattelua Tarjotaan kehitystyökalut (+rajataan asioita) Tarjotaan valmiita ratkaisumalleja, näin ohjelma jaetaan esim. MVC:n, MVVM:n mukaisesti/active record, näin käsittelet asian x Sovelluskauppa/sovellusten keskitetty haku & hallinta Vaatimukset, mitä sovellus saa/ei saa tehdä Käyttöliittymävaatimuksia ja toiminnallisia vaatimuksia (mitä tapahtuu mistäkin napista, mitä tapahtuu, kun ohjelmasta poistutaan jne.) Mahdollinen ohjelmistojen verifiointi Ohjelmistoarkkitehtuurit

79 Käyttöjärjestelmä ja sen vaatimuksia Ohjelmistoarkkitehtuurit

80 Esimerkkejä ekosysteemeistä Facebook, Google, Windows 8, Android, Linux eri versioineen, i- tuotteet, konsolit Raspberryt, Arduinot (alusta ja fyysisiä & ohjelmistokomponentteja, yhteisöä) Pilvimaailman tuotteet Ohjelmistoarkkitehtuurit

81 Pilvinen ekosysteemi esimerkki Ohjelmistoarkkitehtuurit

82 Taksonomiaa Entä nykyaikaistettuna? Software Ecosystem Taxonomy (Bosch, 2009) Ohjelmistoarkkitehtuurit

83 Alusta ja ekosysteemi ohjaavat arkkitehtuuria Sovellusten kehittämisessä ajateltu käytettävän tiettyjä ratkaisutapoja ohjaa toteutettavan ohjelman arkkitehtuurin tähän suuntaan. Helpottaa suunnittelua, mutta jos yritetään tehdä jotain ajatellun muotin ulkopuolelle ulottuvaa, asiat monimutkaisempia Ekosysteemin valintaa, tuki, stabiilius, jatkokehitys, soveltuvuus Useat ekosysteemit ja niiden yhteensovittaminen Ohjelmistoarkkitehtuurit

84 Sopimuksia, vaatimuksia Vaatimuksia: valmiina annettu arkkitehtuuri, työkalujen mahdollisuudet, aihealuerajoitteet, UI, toiminnallisuus, sisältö, teknologia/laitteiston käyttö ( mitä sovellus voi tehdä) Ohjelmistoarkkitehtuurit

85 Oma ekosysteemi? Esimerkki: Tehdään universaali kalenterisovellus, jossa voi ripustella muistilappuja jne. Kalenterioikeuksien jako, Facebook-yhteydet jne. Tietojen säilöntä palvelinpäässä (pilvessä tms.) Alustat: puhelimet (i-sellaiset, Win, Android), tabletit, läppärit/pöytäkoneet Samoja toimintoja, ilmettä, mutta noudatettava kohdealustan sääntöjä Mitä huomiota, mistä osasta tulisi järjestelmän ekosysteemiosio? Ohjelmistoarkkitehtuurit

86 Oman ekosysteemin osia Varsinaiset sovellukset, front-end, käyttöliittymäpuoli Yhteinen osa, tiedon käsittely, tallennus, haku jne. Tämä osa voidaan toteuttaa & suunnitella omien halujen mukaan Käytetyt tekniikat, kielet, toimintatavat, arkkitehtuuriratkaisut Ohjelmistoarkkitehtuurit

87 Sovelluskohtaiset osat, vaatimuksia? Mitä erilaisia vaatimuksia/mahdollisuuksia erikoistettujen osien toteuttamisessa tulee vastaan? Käyttöliittymä ja sujuvuus myyntivaltteina, erikoistetut versiot joka alustalle Tekniikka- ja kieli (millä kielellä käyttäjän osa toteutetaan osaaminen (HTML5, JavaScript, Obj-C, Java, C#, C++ ) Käyttöliittymäpuoli: yhtenäisyys vs. eri alustojen omat vaatimukset Ulkopuoliset kehittäjät/community: rajapintojen dokumentointi, esimerkit, tietoturvallisuus, varmennetaanko ulkopuolinen ohjelmisto jne. Voidaanko tehdä jotain geneeristä yhteistä osaa, jota kaikissa järjestelmissä voitaisiin hyödyntää? esim. Tiedonsiirto, käsittely, paketointi Ohjelmistoarkkitehtuurit

88 Yhteenvetoa Ekosysteemi ajatusmalli (muutakin kuin kasa tarjottua koodia) yhteisö Ekosysteemit ja sovelluskehitys, vaatimukset & hyödyt, ekosysteemi ja oletusarkkitehtuuri Ekosysteemiajattelu omissa projekteissa? Ohjelmistoarkkitehtuurit