Ohjelmistoarkkitehtuurit

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät Johannes Koskinen 1

2 Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti hajautettuja Komponenttien palveluja ei tiedetä tarkasti etukäteen Komponentteja ja niiden lukumäärää ei tiedetä tarkasti etukäteen Järjestelmässä liikkuvan tiedon laatua ei tunneta tarkasti etukäteen 2

3 Viestinvälitysarkkitehtuuri: perusidea rekisteröidyt komponentit 1) luo viesti 2) lähetä välittäjälle Komponenttien yhteinen rajapinta: receive(message) 3) päätä vastaanottaja(t) ja välitä viesti sille/niille rekisteröidyt komponentit 4) vastaanota Viesti Viestinvälittäjä 5) tulkitse/ prosessoi viesti 3

4 Rajapinnat vs. viestit Komponentit, Asiakas-palvelin, Web palvelut (SOA), C++, Java func A(X ) Rajapinta toteuttaa Palvelun tarjoaja Palvelun pyytäjä Viestinvälitysarkkitehtuurit, palveluväylät (ESB), Smalltalk Viesti ACTION = A PAR1 = X lukee Viestin välittäjä Palvelun tarjoaja Palvelun tarjoaja Rajapinta kertoo mitä tehdään ja millä tiedolla, viesti voi kertoa mitä tahansa (mitä tehdään, kuka tekee, millä tiedolla). 4

5 Esimerkkejä Koneiden ohjausjärjestelmät Älykoti Yrityksen liiketoimintojen hallintajärjestelmä Yleisesti: hajautetut järjestelmät, löyhää integrointia vaativat järjestelmät 5

6 Palveluperustainen viestinvälitysarkkitehtuuri Palvelupyyntö Palvelupyyntö Asiakas Viestinvälittäjä Palvelija Palvelun tulos Palvelun tulos Viestinvälittäjä huolehtii siitä, että tulos menee oikealle komponentille 6

7 Esimerkki: Auton huoltotarkkailujärjestelmä moottori cpu jarrut vaihdelaatikko CAN väylä (Controller Area Network) 7

8 Auton huoltotarkkailujärjestelmä: komponenttikaavio CANBusExaminer Messenger ServiceComponent receive(msg) MessageDispatcher send(msg) register(msgtype,component) recordusage() getstate() Sovitin muuntaa viestin palvelukutsuksi BrakeAdater EngineAdapter EngineMonitor returnstate 8

9 Viestinvälitysarkkitehtuurin etuja Helppo muuttaa, lisätä ja poistaa komponentteja tai sovelluksia Vikasietoinen (esim. jos viestillä ei vastaanottajaa), voidaan esim. toistaa viestin lähettämistä Joustava järjestelmäkonfiguraatio Sallii heterogeeniset järjestelmät, sovellusintegraation Sallii sekä synkronisen että asynkronisen kommunikoinnin 9

10 Viestinvälitysarkkitehtuurin haittoja Tehokkuus: viestien kirjoittaminen ja lukeminen Vaikeampi toteuttaa, testata ja ymmärtää kuin perinteinen Jotkut tavalliset asiat vaativat erityistukea (esim. tuloksen palautus, synkronisuus) Syntyy helposti implisiittisiä riippuvuuksia yksiköiden välille 10

11 Harjoitus Topologia Lineaarinen Keskitetty Riippuu palvelusta Rajapinnat Ei riipu palvelusta Täytä arkkitehtuurityylien nimillä 11

12 Kysyttävää?

13 Malli-näkymä-ohjain arkkitehtuurit (Model-View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. 14

14 Malli-näkymä-ohjain arkkitehtuurit (Model-View-Controller, MVC) Lähtökohdat: Sovelluksen tilasta pitäisi pystyä antamaan erilaisia näkymiä Käyttöliittymän pitäisi välittömästi heijastaa sovelluksen tilan muutoksia Käyttöliittymää pitäisi olla helppo muuttaa Sovellus pitäisi voida kohtuullisella työllä siirtää toiselle graafiselle alustalle 15

15 Vastuut Malli Tarjoaa sovellukseen liittyvät loogiset toiminnot ja tiedot Rekisteröi sovelluksen tilasta kiinnostuneet näkymäkomponentit Ilmoittaa rekisteröityneille komponenteille tilan muutoksista Näkymä Huolehtii sovelluksen tilan näyttämisestä näytöllä Ohjain Ottaa vastaan käyttäjän komentoja Muuntaa komennot sovelluksen toiminnoiksi 16

16 Perusajatus komento vaste Ohjain Näkymä sovelluksen toiminto Malli sovelluksen tilan muutos 17

17 Esimerkki Näkymä TextField Tarkkailija Malli Sovelluslogiikka Button Tarkkailija Ohjain 18

18 Esimerkki (Spring MVC) 19

19 MVC malli Observer Model update() * update() attach(observer) detach(observer) notify() getdata() service() attach() getdata() View activate() display() update() Controller handleevent() update() attach() service() 20

20 MVC vuorovaikutus Controller Model View handle- Event service suorita toiminto notify update getdata display 21

21 Kerroksittainen MVC (Esim. verkonhallintasovellukset) Näkymä Käyttäjän komennot Toiminto pyynnöt Ohjain Sovelluslogiikka Model Sovellusaluelogiikka Näytä tulokset Tuota tulokset 22

22 MVC:n edut ja ongelmat Etuja Helppo toteuttaa useita näkymiä samaan tietoon Kaikki näkymät ovat automaattisesti synkronoituja Uusia näkymiä voidaan ajoaikana liittää järjestelmään Käyttöliittymän ulkoasu suhteellisen helposti vaihdettavissa Ongelmia Mahdollisesti turhia näkymien päivityskutsuja Mallidatan kyselyt voivat lisätä suoritusaikaa 23

23 Kysyttävää?

24 Tulkkiarkkitehtuurit Tarve antaa toiminnallisia kuvauksia syötteenä järjestelmälle, esimerkiksi: tarve yhdistellä primitiivisiä toimintoja eri tavoin, jotka eivät ole tiedossa etukäteen tarve erottaa looginen, abstrakti suoritusalusta konkreettisesta (esim. jälkimmäisen vaihtamisen helpottamiseksi) 25

25 Tulkkiarkkitehtuurin perusidea toimintakuvauksen sisäinen esitys Tuloste Jokin toiminnallinen kuvaus (teksti, XML, graafinen, ym.) Tulkki kutsuu Konkreettinen suoritusalusta noudattaa toteutus Syöte Kielen määritys 26

26 Esimerkki 1: Java käännös toimintakuvauksen sisäinen esitys Tavukoodi Ohjelman tulokset Java-ohjelma JVM (C-ohj) kutsuu Suoritusalusta (C ympäristö) noudattaa toteutus Ohjelman syöte Javan määritys 27

27 Esimerkki 2: Taulukkolaskenta Laskettu taulukko sis.esitys Taulukkoskripti Skriptitulkki Taulukkolaskenta noudattaa toteutus Skriptikielen määritys Taulukon alkion arvo 28

28 Esimerkki 3: SQL kyselyt DBMS SQL-kysely SQLtulkki Tietokanta Kyselyn tulos Sovellus 29

29 Esimerkki 4: Tulkitseva DSL toimintakuvauksen sisäinen esitys Tuloste Sovelluksen kuvaus DSL-kielellä Tulkki kutsuu API Alusta noudattaa toteutus Syöte DSL-kielen määritys DSL = Domain-Specific Language 30

30 Kysyttävää?

31 Tulkin suunnittelu: Tulkkisuunnittelumalli (Interpreter) Ongelma: miten esittää tulkittava ohjelma olioina? Ratkaisu: Interpreter AbstractStruct interpret(rep) * TerminalStruct interpret(rep) CompositeStruct interpret(rep) 32

32 Tulkki-suunnittelumallin johtaminen: Kielen rakenteiden esitys luokkina Ongelma: Miten esittää kielen rakenteet luokkina? Esimerkiksi: Script ::= "SCRIPT" Action {";" Action} "END" Action ::= "IF" Expr "THEN" Action "END" identifier "(" Expr ") Expr ::=... Luokkamalli? 33

33 Välisymbolit ja rakenteiset loppusymbolit esitetään luokkina Esimerkiksi: Script, Action, Expr, identifier => luokkia Ei-rakenteiset loppusymbolit (avainsanat, erikoismerkit ym.): SCRIPT END IF THEN ; ( ) Näitä tarvitaan vain jäsennyksen (ja lukemisen) tueksi, eivät olennaisia (nk. konkreettinen syntaksi) 34

34 Mitä tuotossääntö merkitsee luokkien kannalta? Ehdotus: Tuotossääntö merkitsee sitä, että oikean puolen luokat ovat osa-suhteessa vasemman puolen luokkiin. A ::= B C tarkoittaa: OK, mutta entä A ::= B C D E? A 1 1 B C 0..1 A B C D E Ei hyvä... 35

35 Vaihtoehtoiset rakenteet aliluokiksi A ::= B C D E => A ::= A1 A2 A1 ::= B C A2 ::= D E A A1 A2 B C D E 36

36 Rekursiiviset rakenteet Statement ::= CompoundStatement AssignmentStatement CompoundStatement ::= { StatementList } StatementList ::= {Statement ; } Statement * AssignmentStatement CompoundStatement Rekursiokooste 37

37 Esim. Script interpret() 1..* Action interpret() 1 Script ::= "SCRIPT" Action {";" Action} "END" Action ::= CondAction PrimAction CondAction ::= "IF" Expr "THEN" Action "END" PrimAction ::= identifier "(" Expr ")" Expr ::=... CondAction PrimAction Expr interpret() interpret() 1 1 val(): float 1 Identifier name(): String 38

38 Tulkkiarkkitehtuurin edut ja ongelmat Edut: Ajoaikainen looginen suoritusympäristö omassa hallinnassa Tulkittavaa kieltä suhteellisen helppo muuttaa Kielen merkitystä suhteellisen helppo muuttaa Alla oleva ympäristö voidaan helposti vaihtaa Ongelmat: Suorituskyky (epäsuora, ei-natiivi suoritus; sisäisen esityksen muodostaminen) Tilankäyttö (ohjelman sisäinen esitys esim. Tulkki-mallilla voi vaatia paljon tilaa) 39

39 Yhteenvetoa Arkkitehtuuri ~ Domain-tietämys + Tekninen tietämys Domain-tietämys ~ domain-malli Tekninen tietämys ~ arkkitehtuurityylit, suunnittelumallit, yleiset hyvät käytännöt 40

40 Kysyttävää?