Ohjelmistoarkkitehtuurit Kevät 2014

Transkriptio

1 Ohjelmistoarkkitehtuurit Patternien vastaisku Kevät 2014 Samuel Lahtinen (Veli-Pekka Eloranta) Ohjelmistoarkkitehtuurit

2 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

3 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

4 Sovellusalueita Arkkitehtuuri (rakennukset) Ohjelmistoarkkitehtuurit Organisaatio-patternit Scrum-patternit (ja anti-patternit) Global software development patterns Opetuspatternit patternien kirjoittamispatternit...

5 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

6 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

7 Esimerkki: Organisaatio-patternit

8 ltyökonejutut alkavat ny...

9 Esimerkki sovellusalueista

10 Ohjelmistot, miksi työkoneissa?

11 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

12 Tyypillisiä erityispiirteitä: pitkä elinkaari vs

13 Erityispiirteet - skaalautuvuus

14 Erityispiirteet - reaaliaikaisuus

15 Erityispiirteet - turvallisuus

16 Erityispiirteet - hajautus

17 Koneenohjauspatternkieli Designing Distributed Control Systems A Pattern Language Approach

18 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

19 Isolate Functionalities (kaivosporauslaite) Puomin ohjaus Moottorin ohjaus Vaihteiston ohjaus Väylä, esim. CAN Poran ohjaus Rungon ohjaus Human machine interface (HMI)

20 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?

21 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

22 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?

23 Heartbeat Supervisor Node I am alive Tietty ennaltasovittu aikaväli I am alive

24 Toinen ratkaisu: Watchdog Node A Watchdog Node B

25 Tai Watchdog perinteisemmin Node Reset watchdog Tietyin aikavälein Watchdog If( watchdog not reseted){ Reset node }

26 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

27 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.

28 Ratkaisu: Message Queue Node 1 Node 2 Send queue Send queue Receive queue Receive queue

29 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ä.

30 Ratkaisu: Separate Real-time Communicates only over bus

31 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

32 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

33 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

34 Kysyttävää? Ohjelmistoarkkitehtuurit

35 Pilvijutut lpilvilaskenta/palvelut Mitä ne on? Palvelutasot: IaaS, PaaS, SaaS Pilveen siirtyminen? lpilviarkkitehtuureista kevyesti

36 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...

37 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ä

38 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)

39 Mitä syitä siirtyä käyttämään pilvipalveluita?

40 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

41 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

42 Riskit/ongelmat? lmitä huolenaiheita/riskejä pilveen siirtymisessä voisi olla? lmitkä tekijät omassa organisaatiossa voivat vaikuttaa pilven/palvelutason valintaan?

43 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?

44 Pilvi ja patternit ja arkkitehtuurit lpaljon yhteistä asiakas-palvelin-mallien kanssa (yllätys) lhajautettavuus joko (virtuaali)konetasolla, komponenttitasolla l-->yhteistä myös koneenohjausmaailman kanssa

45 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

46 l Esimerkki: Kuorman Tasaaja - Load balancer cloudpatterns.org

47 Viestijonot lmikä arkkitehtuurityyli tästä tulee mieleen? lmissä muussa yhteydessä viestijonot tulivat esille? Anna Ruokonen, PalPo

48 Pilvijutuista llisää tietoa, palvelupohjaiset järjestelmät kurssi lyleisesti pilvitarinoita on netti pullollaan lesimerkkejä suunnittelumalleista Amazonin pilvimainos/periaatteita/patterneita:

49 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)