Ohjelmistoarkkitehtuurit Refaktorointia, ohjelmien ylläpitoa ja evoluutiota Kevät 2016 Samuel Lahtinen http://www.cs.tut.fi/~ohar/ Ohjelmistoarkkitehtuurit 2016 1
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
Mitä on refaktorointi?
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.
Mitä erilaisia refaktorointitoimia on?
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)
Refaktorointi ja työkalut IDE:t, modernit koodieditorit (refaktorointitoimien tuki, uudelleennimeäminen, funktion parametrien muutokset) Erilaiset lisätyökalut, esim. https://www.jetbrains.com/resharper/
Esimerkkejä refaktorointitoimenpiteistä class CircleArea { const double PI = 3.141592; 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 = 3.141592; 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 );
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();
Esimerkkejä refaktorointitoimenpiteistä Hierarkian litistäminen (collapse hierarchy) Kantaluokan lisääminen (extract superclass)
Esimerkkejä refaktorointitoimenpiteistä Korvataan saman asian eri tietotyypeille tekevät funktiot / tai luokkahierarkia Template-funktiolla (tai luokalla)
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ä: http://www.refactoring.com/catalog/ https://refactoring.guru/catalog
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ä
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öä.
Miksi refaktoroida?
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
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
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
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
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
Refaktorointipatterneja?
Refaktorointi on turhaa? http://www.itworld.com/article/2891140/study-finds-thatrefactoring-doesn-t-improve-code-quality.html http://arxiv.org/ftp/arxiv/papers/1502/1502.03526.pdf 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
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
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
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 (http://www.sonarqube.org/ ) http://en.wikipedia.org/wiki/list_of_tools_for_static_code_analysis
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 (http://www.sonarqube.org/ ) http://en.wikipedia.org/wiki/list_of_tools_for_static_code_analysis
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
Refaktorointi versiohallinnassa
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: https://github.com/bbatsov/rubystyle-guide 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
Oheismateriaalia http://refactoring.com/ https://msdn.microsoft.com/en-us/library/719exd8s.aspx https://refactoring.guru/
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)
Perintönä saatua koodia (legacy code)
Miksi legacy-koodi on hankalaa? Ohjelmistoarkkitehtuurit 2016 6.4.2016 33
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 2016 6.4.2016 34
Legacyn kanssa puljaaminen Tunnista vaatimukset Pyri ymmärtämään koodia Muokkaa koodia Kirjoita testit (tämä voi olla myös toisena kohtana) Ohjelmistoarkkitehtuurit 2016 6.4.2016 35
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 2016 6.4.2016 36
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 2016 6.4.2016 37
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 2016 6.4.2016 38
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 2016 6.4.2016 39
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 2016 6.4.2016 40
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 2016 6.4.2016 41
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 2016 6.4.2016 42
Toiminnallisuuden vaihto Ohjelmistoarkkitehtuurit 2016 6.4.2016 43
Uudelleenkäyttö Ohjelmistoarkkitehtuurit 2016 6.4.2016 44
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 2016 6.4.2016 45
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 2016 6.4.2016 46
Referenssejä, luettavaa Kirja: Working Effectively with Legacy Code, Michael Feathers Ohjelmistoarkkitehtuurit 2016 6.4.2016 47
Viestipohjaisten yritysjärjestelmien suunnittelumallit
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 2016 6.4.2016 49
Yritystietojärjestelmiä Taustamateriaalia, perusperiaatteet valideja, uusimmat alustat/tekniikat puuttuvat esimerkeistä: Enterprise Integration Patterns: http://www.eaipatterns.com/ Patterns of Enterprise Application Architecture by (Martin Fowler with Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford) http://architects.dzone.com/articles/enterprise-integration http://technet.microsoft.com/en-us/library/hh393531.aspx Mallintaminen jne. työkaluja ja mallinnustekniikoita tarjolla, esimerkki Enterprise systems architect: http://www-03.ibm.com/software/products/en/ratisystarch Ohjelmistoarkkitehtuurit 2016 6.4.2016 50
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 2016 6.4.2016 51
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 2016 6.4.2016 52
Tilausten vastaanotto Viesti Kanava Reititys Muunnos Sovellus - - - - - - - - - - - - - - - - - - - - - Sovellus Sovitin Sovitin Hallinta ja monitorointi Ohjelmistoarkkitehtuurit 2016 6.4.2016 53
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 2016 6.4.2016 54
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 2016 6.4.2016 55
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 2016 6.4.2016 56
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 2016 6.4.2016 57
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 2016 6.4.2016 58
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 2016 6.4.2016 59
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 2016 6.4.2016 60
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 2016 6.4.2016 61
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 2016 6.4.2016 62
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 2016 6.4.2016 63
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 2016 6.4.2016 64
Kysyttävää?
Reititys Viesti Kanava Reititys Muunnos Sovellus - - - - - - - - - - - - - - - - - - - - - Sovellus Sovitin Sovitin Hallinta ja monitorointi Ohjelmistoarkkitehtuurit 2016 6.4.2016 66
Tilausten käsittely tarkista varasto tarkista asiakas [OK] Poikkeusten käsittely toimita tavara lähetä lasku Ohjelmistoarkkitehtuurit 2016 6.4.2016 67
Tilausten käsittely Asiakashallinta Sisältöperustainen reititin kelvollinen tilaus - - - - - - - - - - - - - - - - - - - - - Julkaisijatilaaja Julkaisijatilaaja Laskutus Toimitus Varastohallinta Yhdistäjä - - - - - - - - - - - - - - - - - - - - - epäkelpo tilaus Ohjelmistoarkkitehtuurit 2016 6.4.2016 68
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 2016 6.4.2016 69
Tilausten käsittely Asiakashallinta Sisältöperustainen reititin kelvollinen tilaus - - - - - - - - - - - - - - - - - - - - - Laskutus Varastohallinta Yhdistäjä - - - - - - - - - - - - - - - - - - - - - Toimitus alihankkija/muu toimittaja - - - - - - - - - - - - - - - - - - - - - epäkelpo tilaus Ohjelmistoarkkitehtuurit 2016 6.4.2016 70
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 2016 6.4.2016 71
Hallinta ja monitorointi Viesti Kanava Reititys Muunnos Sovellus - - - - - - - - - - - - - - - - - - - - - Sovellus Sovitin Sovitin Hallinta ja monitorointi Ohjelmistoarkkitehtuurit 2016 6.4.2016 72
Ä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 2016 6.4.2016 73
Yhteenveto Erillisiä osajärjestelmiä, niiden integrointia Tiedon välitys, tiedon käsittely ja vaiheet olennaisia Missä muodossa tietoa käsitellään, tietomalli? Ohjelmistoarkkitehtuurit 2016 6.4.2016 74
Ekosysteemijuttuja
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 http://www.janbosch.com/jan_bosch/composition_files/sp LC09-SoftwareEcosystems-Accepted.pdf Ohjelmistoarkkitehtuurit 2016 6.4.2016 76
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 2016 6.4.2016 77
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 2016 6.4.2016 78
Käyttöjärjestelmä ja sen vaatimuksia Ohjelmistoarkkitehtuurit 2016 6.4.2016 79
Esimerkkejä ekosysteemeistä Facebook, Google, Windows 8, Android, Linux eri versioineen, i- tuotteet, konsolit Raspberryt, Arduinot (alusta ja fyysisiä & ohjelmistokomponentteja, yhteisöä) Pilvimaailman tuotteet Ohjelmistoarkkitehtuurit 2016 6.4.2016 80
Pilvinen ekosysteemi esimerkki http://www.cloudel.com/dell-launches-new-version-of-openstack-poweredcloud-solution/ Ohjelmistoarkkitehtuurit 2016 6.4.2016 81
Taksonomiaa Entä nykyaikaistettuna? Software Ecosystem Taxonomy (Bosch, 2009) Ohjelmistoarkkitehtuurit 2016 6.4.2016 82
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 2016 6.4.2016 83
Sopimuksia, vaatimuksia Vaatimuksia: valmiina annettu arkkitehtuuri, työkalujen mahdollisuudet, aihealuerajoitteet, UI, toiminnallisuus, sisältö, teknologia/laitteiston käyttö ( mitä sovellus voi tehdä) http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx https://developer.apple.com/app-store/review/ https://developer.apple.com/design/tips/ Ohjelmistoarkkitehtuurit 2016 6.4.2016 84
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 2016 6.4.2016 85
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 2016 6.4.2016 86
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 2016 6.4.2016 87
Yhteenvetoa Ekosysteemi ajatusmalli (muutakin kuin kasa tarjottua koodia) yhteisö Ekosysteemit ja sovelluskehitys, vaatimukset & hyödyt, ekosysteemi ja oletusarkkitehtuuri Ekosysteemiajattelu omissa projekteissa? Ohjelmistoarkkitehtuurit 2016 6.4.2016 88