Ohjelmistoarkkitehtuurit Patternien vastaisku Kevät 2014 Samuel Lahtinen (Veli-Pekka Eloranta) http://www.cs.tut.fi/~ohar/ Ohjelmistoarkkitehtuurit 2014 12.2.2014 1
Tarjolla tänään Yleisesti patterneista/suunnittelumalleista Suunnittelumalli!= GOF pattern Koneenohjausjärjestelmien introa Erityispiirteitä Yleisiä vaatimuksia Jotain patterneita Kevyttä alapilveä Superlyhyesti pilvestä pilvi-patterneita Ohjelmistoarkkitehtuurit 2014 12.2.2014 2
Patterneista (taas) Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. Pattern is at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing. - Christopher Alexander, Timeless Way of Building, page 247
Sovellusalueita Arkkitehtuuri (rakennukset) Ohjelmistoarkkitehtuurit Organisaatio-patternit Scrum-patternit (ja anti-patternit) Global software development patterns Opetuspatternit patternien kirjoittamispatternit...
Suunnittelumallien esitystavat Canonical Form ja Gof (Design patterns: Elements of reusable object-oriented software, Gamma et. Al.) Name Alias (optional) Context Problem Forces Solution Example (optional) Resulting Context Rationale (optional) Known Uses Related Patterns Name Also Known As Applicability Intent Motivation Participants, structure, collaborations, implementation Sample code Consequences Known Uses Related Patterns
Mallikielet Joukko saman sovellusalueen patterneja voidaan organisoida mallikieleksi suositellun käyttö järjestyksen mukaan Mallikieli rakentaa kokonaisuuden (vrt. GoF!) Pattern collection or Pattern set!= Pattern language Antaa sanaston sovellusalueen kehittäjille Ei ole hierarkinen rakenne! Mahdollisuus ratkaista ongelmia loogisessa järjestyksessä, monia polkuja
Esimerkki: Organisaatio-patternit
ltyökonejutut alkavat ny...
Esimerkki sovellusalueista
Ohjelmistot, miksi työkoneissa?
Ohjelmistot, miksi työkoneissa? ltuottavuus paranee Toimintojen automatisointi Koneen käyttäjän opastaminen Tehokkuus Helpompi päivitettävyys lhuoltotarvetta voidaan ennakoida lintegrointi tuotannonohjausjärjestelmiin ja laivueenhallintaan (fleet management) lkommunikointi muiden työkoneiden kanssa
Tyypillisiä erityispiirteitä: pitkä elinkaari vs
Erityispiirteet - skaalautuvuus
Erityispiirteet - reaaliaikaisuus
Erityispiirteet - turvallisuus
Erityispiirteet - hajautus
Koneenohjauspatternkieli Designing Distributed Control Systems A Pattern Language Approach
Suunnittelun aloitus ljo käytössä suunnittelumallikieli, valitaan kielen juuresta sopiva pattern ja soveltaa sitä ltai halutaan ratkaista yleinen ongelma: mikä on järkevät tapa luoda suolautettu järjestelmä suuremmalla laitteelle/koneelle? Miten rakentaa suurempi koneenohjausjärjestelmä järkevästi? lanti-pattern-versio: Keskitetään kaikki toiminnallisuuden ohjaus yhteen isoon mötikkään, joka vastaa jokaisen laitteen ja vekottimen kontrolloimisesta
Isolate Functionalities (kaivosporauslaite) Puomin ohjaus Moottorin ohjaus Vaihteiston ohjaus Väylä, esim. CAN Poran ohjaus Rungon ohjaus Human machine interface (HMI)
Havaitaan ongelma/ saadaan vaatimuksia Entä jos väylä halutaan vaihtaa? Jokaisen solmun sovellus on riippuvainen valitusta väyläteknologiasta Syitä muutokseen Tuki loppuu pitkän elinkaaren aikana Valmistaja menee konkurssiin Suunnittelun aikana havaitaan, ettei valitun teknologian kapasiteetti riitä Halutaan varautua tulevaan (esim. Väyläkapasiteetin kasvutarve) Ongelma/kysymys: Kuinka vaihtaa valittu väyläteknologia tai protokolla ilman että (laitteiden, jne) sovelluskoodia ei tarvitse muuttaa?
Bus Abstraction Puomin ohjaus Send( node3, data, repeat=no) Poran ohjaus Callback( node1, data) Bus abstraction Väylä, esim. CAN lähetä väyläspesifisessä muodossa Bus abstraction vastaanota väylän käyttämässä muodossa
Entäpä jos väylä katkeaa tai solmu (node) hajoaa? ltilanne pitäisi havaita jotenkin, jotta asialle voidaan tehdä jotain l How to make sure that a node or a bus will not fail undetected? lkuinka varmistua siitä, ettei väylän tai solmun hajoaminen jää huomaamatta?
Heartbeat Supervisor Node I am alive Tietty ennaltasovittu aikaväli I am alive
Toinen ratkaisu: Watchdog Node A Watchdog Node B
Tai Watchdog perinteisemmin Node Reset watchdog Tietyin aikavälein Watchdog If( watchdog not reseted){ Reset node }
Arkkitehtuuri tähän mennessä Watchdog Puomin ohjaus Moottorin ohjaus HB Vaihteiston ohjaus HB Bus abstraction Bus abstraction Bus abstraction Väylä, esim. CAN Bus abstraction Poran ohjaus Bus abstraction Rungon ohjaus HB Bus abstraction HMI
Entäpä jos viestejä tulee väylältä enemmän kuin ehditään käsitellä? Kaikki viestit tulisi käsitellä, yhtäkään viestiä ei saisi jättää huomiotta. Lähetettävien (tai vastaanotettavien) viestien määrää ei voida ennakoida kehitysaikana Viestit tulisi käsitellä siinä järjestyksessä kuin ne vastaanotetaan. Kaikki viestit tulisi käsitellä mahdollisimman nopeasti.
Ratkaisu: Message Queue Node 1 Node 2 Send queue Send queue Receive queue Receive queue
Halutaan tarjota korkean tason palveluja Korkean tason palvelut eivät ole reaaliaikaisia. Korkean tason palvelut eivät saa häiritä reaaliaikatoimintoja, koska se voisi johtaa järjestelmän virheelliseen toimintaan. Testattavuus: Reaaliaikatoimintojen testaaminen erillään korkean tason palveluista pitäisi olla mahdollista. Korkean tason ohjelmistojen kehittäminen on helpompaa kun ei tarvitse välittää reaaliaikavaatimuksista. Reaaliaikatoimintojen tulee toimia tietyissä rajoissa, esim. Jarrujen ja muiden ohjausten vasteaika tulee olla riittävä.
Ratkaisu: Separate Real-time Communicates only over bus
Watchdog HB HB Puomin Moottorin Vaihteiston ohjaus ohjaus ohjaus Bus SQ RQ Bus SQ RQ Bus SQ RQ Abstraction Abstraction Abstraction Bus Bus Bus Abstraction SQ RQ Abstraction SQ RQ Abstraction SQ RQ Väylä, esim. CAN Bus SQ RQ Bus SQ RQ Bus SQ RQ Bus Abstraction Abstraction Abstraction Abstraction Bus Bus Bus abstraction SQ RQ abstraction SQ RQ abstraction SQ RQ SQ RQ Poran Runkon Rungon ohjaus ohjaus HMI HB PC
Lisää vaatimuksia/ongelmia Laitteisto saattaa vaihtua, ei haluta vaihtaa joka kerta ohjelmistoa Abstrahoidaan laitteisto, Hardware abstraction layer (erillinen rajapinta, jonka takana laitteisto on. Vertaa ajurit ja tietokone) sovellus OS HAL Application interface HAL drivers Rauta
Yhteenvetoa koneenohjausjutuista Koneenohjausmaailman arkkitehtuuriratkaisut, sama ideologia Melko yksinkertaisia hyväksi havaittuja toimintatapoja Arkkitehtuuriratkaisujen taustalla ongelma/vaatimus TTY:llä tämän alan asiantuntemusta: Kirja tulossa Wellu ja kumppanit, vanhempaa materiaalia esimerkiksi http://www.cs.tut.fi/~kk/patternlanguage.pdf http://patterns.cs.tut.fi/
Kysyttävää? Ohjelmistoarkkitehtuurit 2014 12.2.2014 34
Pilvijutut lpilvilaskenta/palvelut Mitä ne on? Palvelutasot: IaaS, PaaS, SaaS Pilveen siirtyminen? lpilviarkkitehtuureista kevyesti
Mikä on pilveä? Periaate: pilvilaskenta tarjoaa näennäisesti loputtomat laskentaresurssit tietoverkon yli Käyttäjä voi käynnistää, pysäyttää ja skaalata palveluita mielensä mukaan Ideatasolla kuten vesi tai sähkö: Laskentaa tarjotaan samaan tapaan, tarjotaan ja laskutetaan käytön mukaan, ei tarvitse itse huolehtia rautapuolen asioista Yksityinen pilvi...
Mikä on pilveä? lkriteeristöä: Palvelu on käytettävissä selaimen tai palvelurajapintojen avulla (ei tarvetta erillisille asennuksille) lei pääomainvestointeja käytön aloittamisen yhteydessä lmaksat vain käytöstä
Pilvipalveluiden eri tasot linfrastructure as a Service IaaS Tietokonejärjestelmätason palvelu, usein virtuaalikone, joka on heti käyttövalmis lplatform as a Service PaaS Tarjoaa alustan ja ohjelmistot palveluna (kehityskalut, tietovarastot jne.) Usein PaaSin päällä ja sisältää SaaS sovelluksia lsoftware as a Service SaaS Iaas ja Paas tarkoitettu ohjelmistokehittäjille, SaaS yleensä suoraan loppukäyttäjälle Käyttö suoraan selaimella tai/ja API:n läpi (SOApalvelut)
Mitä syitä siirtyä käyttämään pilvipalveluita?
Mitä syitä siirtyä käyttämään pilvipalveluita? lhinta, ei laitteistokuluja, henkilökuntaa (laitteistoon liittyen) lsaavutettavuus (jos palveluiden tarjoajat luotettavia) ljoustavuus, skaalautuvuus lhelpompi dumpata epäonnistuneet projektit... lvuokrausperiaate
Arkkitehtuureista... Separation of : Presentation, Business logic Data storage Processing node Processing node Processing node Get job Transaktiopohjainen sovellusarkkitehtuuri Publish results Job queue Push job Get results Data manager Grid application architecture VM 1 VM 2 VM 3 Virtualization layer Host operating system Korkean tason kerrosarkkitehtuuri Hardware
Riskit/ongelmat? lmitä huolenaiheita/riskejä pilveen siirtymisessä voisi olla? lmitkä tekijät omassa organisaatiossa voivat vaikuttaa pilven/palvelutason valintaan?
Pilvikysymyksiä? lmitä asioita halutaan siirtää kolmannen osapuolen hallintaan? ltietosuoja, varmuuskopiot, käytetyn palvelutoimittajan odotettu elinikä, vendor lock, palvelusopimukset ja niiden muutokset, lisenssit, millä tasolla palveluihin pääsee käsiksi, tarjolla olevat ohjelmistot jne. l-->millä tasolla palveluita hankitaan? lkustannukset ja osaaminen Minkälaista osaamista porukasta löytyy? Jotain sivistyneitä arvauksia kustannuksista?
Pilvi ja patternit ja arkkitehtuurit lpaljon yhteistä asiakas-palvelin-mallien kanssa (yllätys) lhajautettavuus joko (virtuaali)konetasolla, komponenttitasolla l-->yhteistä myös koneenohjausmaailman kanssa
Pilvi ja patterneja / hyviä toimintatapoja lno single point of failure lreplication, monitoring, load balancing, backups, snapshots l separate real-time Priorisointi toimintojen tärkeyden perusteella internet DB master DB slave Cloud front Permanent storage
l Esimerkki: Kuorman Tasaaja - Load balancer cloudpatterns.org
Viestijonot lmikä arkkitehtuurityyli tästä tulee mieleen? lmissä muussa yhteydessä viestijonot tulivat esille? Anna Ruokonen, PalPo
Pilvijutuista llisää tietoa, palvelupohjaiset järjestelmät kurssi lyleisesti pilvitarinoita on netti pullollaan lesimerkkejä suunnittelumalleista http://www.cloudpatterns.org/ http://cloudcomputingpatterns.org/ Amazonin pilvimainos/periaatteita/patterneita: http://www.cohaa.org/content/sites/default/files/aws%20-%20how%20to%20think%20cloud%20-%20steve%20riley.pdf
Yhteenveto lsuunnittelumallit/patternit, jotain muutakin kuin kooditason toteutuskikkoja lsamoja ratkaisuja eri maailmoissa, jos ongelmat samankaltaisia, samankaltaiset ratkaisutkin voivat toimia Yleiskäyttöisyys (Esimerkiksi: viestijonot, kahdennukset, työjonot, vahtikoirat/sydämenlyönnit)