Ohjelmistoarkkitehtuurit. Kevät 2014

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät 2014 Samuel Lahtinen 1

2 Infoa Vierailuluentojen korviketehtävä kotisivuilla Viikkoharkkojen bonustehtävä julkaistu Tarvittaessa voit myös tehdä lisäbonuksena viikkoharkkojen lisätehtävän korvaamaan lisää puuttuvia vierailuluentoja (tai päinvastoin) Seuraavilla viikoilla viikkoharkoissa neuvontapäivystyssettiä (TTY) 2

3 Tänään ohjelmassa Ohjelmistoekosysteemeistä Miten vaikuttavat arkkitehtuuriin? Mitä oman ekosysteemin suhteen kannattaa miettiä Viestipohjaisia yritysjärjestelmäpatterneita Esimerkki tavasta dokumentoida asioita Jotain normaalin ohjelmistoarkkitehtuurin ja yritysjärjestelmämallien jne. väliltä. 3

4 Ekosysteemijuttuja

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

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

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

8 Käyttöjärjestelmä ja sen vaatimuksia 8

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

10 Pilvinen ekosysteemi esimerkki 10

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

12 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 12

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

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

15 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 15

16 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 16

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

18 Viestipohjaisten yritysjärjestelmien suunnittelumallit

19 Yritystietojärjestelmiä Erilaisia tapoja yhdistellä bisnes, kehitystyö, lopputuote ja toisaalta kuvata järjestelmän osia, kommunikaatiota 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ä 19

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

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

22 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

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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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 31

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

33 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

34 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

35 Kysyttävää?

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

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

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

39 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

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

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

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

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

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

45 Kysyttävää?