Ohjelmistoarkkitehtuurit. Kevät 2014

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät 2014 Samuel Lahtinen (Johannes Koskinen) 1

2 Yleisiä asioita Luennot keskiviikkoisin 10:15- Viikkoharjoitukset jatkuvat taas 8.4. Arviointien paikat IDLEssä & kurssin sivuilla Vierailuluentojen korvaaminen (julkaisun lukeminen & kysymyksiin vastailu) Töihin laitokselle? 2

3 Presemo-testi m31.screen.io/ohar Tai kurssin kotisivujen kautta: 3

4 Aiemmin käytyä Muunneltavuuden hallintaa ==Miten mahdollistaa tiettyjen asioiden muuntelu, ylläpito, päivittäminen ilman hirveää tuskaa (Huono autovertaus ) 4

5 11. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia 5

6 Uudelleenkäyttö opportunistinen: hyödynnetään aikaisempaa koodia, joka sattumalta sopii uuteen sovellukseen. suunniteltu: organisaatio käyttää resursseja yleisesti uudelleenkäytettävien ohjelmistojen kehittämiseen, jotka tarjoavat yrityksen alaan sopivat abstraktiot ja variaatiopisteet. oppotunistinen tapa ei toimi hyvin käytännössä alhaalta-ylös: potentiaalisesti uudelleenkäytettävät komponentit lisätään yleisesti käytössä olevaan komponenttikirjastoon, josta haetaan valmiita komponentteja uuteen sovellukseen. ylhäältä-alas: uudelleenkäytettävät ohjelmistot tehdään johonkin laajempaan kokonaisuuteen sopiviksi (esim. rajapinnat, arkkitehtuurit, kehykset) alhaalta-ylös tapa johtaa matalan tason uudelleenkäyttöön 6

7 Määritelmiä Tuoteperhe: joukko koordinoidusti kehitettyjä ohjelmistotuotteita, joilla on samankaltainen rakenne ja toiminta. Tuotelinja: kaikki artifaktit, välineet ja prosessit, jotka tukevat tuoteperheen jäsenten kehittämistä ja ylläpitoa. Tuoterunko, tuotealusta: tuoteperheen yhteinen ohjelmistoalusta Tuoterunkoarkkitehtuuri, tuoteperhearkkitehtuuri: tuoteperheen yhteinen arkkitehtuuri, tuoterungon arkkitehtuuri 7

8 Tuoterunko = yhteiseen arkkitehtuuriin ja alustaan perustuva ohjelmistojen uudelleenkäyttö Suunniteltu ja ylhäältä-alas Tuoterunkoarkkitehtuurit (Product-line Architectures): azayeri Software Product Line Engineering: Foundations, Principles and Techniques:Klaus Pohl, Günter Böckle, Frank J. van der Linden (2005) ViewFBC /Pohl_et_al%282005%29.pdf 8

9 Anna esimerkkejä tuoterunkoajatteluun sopivista sovellusalueista Uta, Vaasa, Turku: Presemo (m31.screen.io/ohar) TTY: huutelu tai oma Presemo-kohta 3min mietintäaikaa 9

10 Tuoterunkoihin pohjautuva ohjelmistokehitys Keskeiset tavoitteet: merkittävä uudelleenkäyttö, lyhyempi kehitysaika, parempi laatu vähemmillä resursseilla, yhdenmukainen ja rationalisoitu kehitysprosessi, yhdenmukaiset tuotteet Edellytykset: halutaan tuoteperhe, jolla on riittävästi yhteisiä ominaisuuksia ja hyvin ymmärretty variaatio: vaatimusten on määriteltävä soveltamisala, yhteiset vaatimukset ja variaatiopisteet Tuoterunkotyyppisiin tilanteisiin joudutaan joskus myös ilman selvää tuoteperhekonseptia: Tuntemattomat vaatimukset johtavat usein variaatiopisteisiin Avoin lähdekoodi on usein tulkittavissa tuoterunkona Tuotteista halutaan räätälöitäviä 10

11 Tuoterunkoihin pohjautuvan ohjelmistokehityksen näkökulmat Liiketoimintanäkökulma Milloin tuoterunkolähestymistapa kannattaa taloudellisesti? Millaisten taloudellisten mallien pohjalta voidaan tehdä päätöksiä? Organisaationäkökulma Miten organisaatio voi omaksua tuoterunkoajattelun ja tukea tuoterunkoon pohjautuvaa kehittämistä? Prosessinäkökulma Millainen kehitysprosessi sopii tuoteperheille? Tekninen näkökulma Millaisia arkkitehtuurimalleja ja teknologioita käytetään tuoterungoille? 11

12 Liiketoimintanäkökulma 4C 3C takaisinmaksu perinteinen tuoterunko 2C 1C alustan rakentaminen Sovellusten lukumäärä 12

13 Liiketoimintanäkökulma Perustuu työmääräarviomenetelmiin In H.P. et al.: A quality-based cost estimation model for the product-line life-cycle. CACM 49 (2006),

14 Esimerkki ( oikea ) Sovellusalue: videopelit Perinteinen Santelices R.A., Nussbaum M.: A framework for the development of videogames. Software Practice & Experience 31 (2001), peli 2. peli 3. peli työtuntia Kehykseen perustuva Kehyksen rakentaminen + koulutus Suorituskyky: aika +70% tila +200% 14

15 pulmapelitehdas Yritys pohtii mahdollisuuksia lähteä tuottamaan kännykkään pulmapelituoterunkoalustaan perustuen (Tetris, palluroiden, värien jne. yhdistelypelit) Oletetaan, että pulmapelisovelluksen toteuttamisen keskihinta on e, ja sovelluksen kehittäminen kestää 6kk (ilman tuotealustaa). Millä edellytyksillä yrityksen kannattaa investoida tuotealustaan, jos tuotealustan perustamiskustannukset ovat e ja toteutustyöhön kuluu 12kk, ja tämän jälkeen pelisovelluksen hinta on vain e, ja aikaa tarvitaan vain 2kk per peli? Kuinka monen pelin jälkeen tuoterunko maksaisi itsensä takaisin siinä tapauksessa, että ensimmäinen peli tehdään erikseen rinnan tuotealustan kanssa, ottaen huomioon, että tämän pelin siirtäminen tuotealustan päälle maksaisi e? Tarkastele asiaa eri puolilta yrityksen johdon kannalta, ottaen huomioon mahdolliset liiketoimintatavoitteet, henkilöresurssien käyttö, reagointikyky markkinoihin ym. 15

16 Uudelleenkäytön kypsyystasot Konfiguroitava tuoterunko (automaattinen tuki tuotteen rakentamiselle) Kypsyystaso Yhteinen arkkitehtuuri, variaatiopisteet (tuoterunko) Yhteinen alusta, yhteistä toiminnallisuutta Standardisoitu infrastruktuuri (yhteinen OS, DB, GUI jne.) Riippumattomat tuotteet 16

17 Hierarkkinen tuoterunko Jan Bosch 17

18 Organisaation kypsyys suhteessa arkkitehtuuriin Arkkitehtuuri selittää järjestelmää Arkkitehtuuri ohjaa järjestelmän rakentamista Arkkitehtuuri mahdollistaa erilaisten järjestelmien rakentamisen (tuoterunko) organisaation kypsyys 19

19 Kysyttävää?

20 Eri tapoja lähteä tuoterunkopohjaiseen ohjelmistokehitykseen Onko yrityksellä aikaisemmin ohjelmistoa kohdealueella? Tehdäänkö tuoterungon kehittely vähitellen vai yhdellä kertaa? Muunnetaan olemassa olevia komponentteja yleisemmiksi Korvataan olemassa olevat komponentit tuotealustalla Kehitetään uusi tuotealusta asteittain kasvavalle tuoteperheelle (ei olemassa olevaa ohjelmistoa) Kehitetään uusi tuotealusta heti koko suunnitellulle tuoteperheelle (ei olemassa olevaa ohjelmistoa) 21

21 Tuoterunkoprosessi Vaatimusmäärittely sisältyy Sovellusalueen käsitemalli Muunneltavuusvaatimukset, piirremalli Yhteiset vaatimukset Alustan suunnittelu Alustakehitysprosessi Tuoterunkoarkkitehtuuri Tuoterunkorajapinta Arviointi Alustan toteutus Alusta Variaationhallinta Vaatimusmäärittely Tuotevaatimukset Tuoteen toteutus Tuotekohtainen koodi Tuotekehitysprosessi 22

22 Vaatimukset ja suunnittelupäätökset Viime kädessä hankintasopimus määrittelee vaatimukset, kaikki sen jälkeen tulevat päätökset ovat suunnittelua Tuoterungon tapauksessa ei yleensä ole hankintasopimusta, vaan tuoterunko tehdään yrityksen sisäiseen käyttöön (erityisesti) tuoterungon tapauksessa ei selvää eroa vaatimusten ja suunnittelun välillä: myös vaatimukset suunnitellaan 23

23 Tuoterunko-organisaatio Tuoterungon mahdollisuudet Tuoterungon mahdollisuudet Sovellusalueen ymmärrys Arkkitehtuuriosaaminen Abstrahointikyky Teknologiatuntemus Kommunikaatiokyvyt Markkinointi Asiakkaan tarpeet Tuoterungon ymmärtäminen, sitoutuminen, puolustaminen ( Champion ) Johto Vaatimukset Tuotteen ominaisuudet Asiakas Tuotteen ymmärrys Asiakkaan tarpeiden ymmärrys Komponenttipohjainen kehitys Räätälöintikyky Toteutustekniikoiden tuntemus Tuoterunko ryhmä Komponentit Päivitykset Vaatimukset Mahdollisuudet Tuoteryhmät Tuotteet Palaute 24

24 Tuoterunkoja tukevia teknologioita Komponenttiteknologiat Olioteknologiat, kehykset Mallintamisteknologiat, UML Sovellussuuntautuneet kielet, XML Tekstuaalisten ja visuaalisten kielten rakentamisympäristöt 25

25 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus Koodi 26

26 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus DSL = Domain- Specific Language DSL koodi DSL kehitin Koodi Koodi 27

27 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus Yhteinen arkkitehtuuri ja sovellusalueen tuki DSL = Domain- Specific Language DSL koodi DSL kehitin Koodi Koodi Koodi Alusta tuoterunkorajapinta 28

28 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus Yhteinen arkkitehtuuri ja sovellusalueen tuki DSL = Domain- Specific Language DSL koodi DSL kehitin Koodi Koodi Koodi Alusta tuoterunkorajapinta 29

29 Kysyttävää?

30 Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Kerrostyyli tuoterunkoarkkitehtuureille Sovellusalusta Arkkitehtuurialusta Resurssialusta 31

31 Esimerkki: EJB-pohjainen tuoterunko Tuote Talletustilien hallintajärjestelmä Sovellusalusta Arkkitehtuurialusta Pankkisovellustuki EJB: hajautettu asiakas-palvelintuki Resurssialusta Tietokantapalvelut, tietoliikennepalvelut, KJ vrt. yleinen liiketoimintajärjestelmien kerrosarkkitehtuuri 32

32 Harjoitus Oletetaan, että aikaisemmin esimerkkinä ollut auton monitorointijärjestelmä halutaan muuntaa tuoterungoksi, jonka avulla voidaan luoda monitorointijärjestelmiä erilaisille ajoneuvoille. Anna tällaiselle tuoterungolle kerrosarkkitehtuuri nelikerrosarkkitehtuurimallin mukaisesti. 33

33 CANBus CANFilter MessageDispatcherIF XMLMsg Message Dispatcher Msg type(): MsgType Component receive(msg) send(msg) register(msgtype,component) BrakeViewIF update() Brake- View BrakeModelIF BrakeController handleevent(event) BrakeState recordusage checkcondition register(view) getstate() setstate() GSMComp sendreport DBAccess 34

34 Harjoitus Sovellus Sovellusalusta Arkkitehtuurialusta Resurssialusta 35

35 Kerrostyyliin perustuvan tuoterungon suunnittelu 1. Päätä yleiset tukipalvelut ja suunnittele niiden abstrahointi 2. Päätä perusarkkitehtuurityyli ja suunnittele sen tarvitsema infrastruktuuri (esim. viestinvälitys, asiakas-palvelin) 3. Suunnittele tuoteperheen yhteiset komponentit ja variaatiopisteiden toteutus 4. Huom: joku kerroksista voi myös puuttua tai olla hyvin ohut 36

36 Kerrosarkkitehtuuri auttaa hallitsemaan tuoterunkoa Mihin osiin vaikuttavat tietokantamuutokset? Miten varmistutaan, että ei muuteta tuoterungon perusarkkitehtuuria? Miten varmistutaan, että ei tuoda yksittäiseen tuotteeseen liittyviä asioita perusarkkitehtuuriin? Miten varmistutaan, että ei sotketa tuotekohtaisia asioita sovellusaluekohtaisiin asioihin? Mitkä osat vaikuttavat eniten laatuominaisuuksiin? Mitä osia on (todennäköisesti) muutettava, jos laatuvaatimukset muuttuvat? 37

37 Esimerkkejä tuoterungoista Kännykkäalustat Vakuutusjärjestelmäalustat Pankkijärjestelmäalustat Tietokone- ja kännykkäpelialustat Koneenohjausjärjestelmäalustat 38

38 ISA arkkitehtuuri (Nokia) Veijola

39 Tuoteperhe-esimerkki (Vignet terveyspalveluita) 40

40 Ohjelmistorunko ja laitteet 41

41 S60 Product Platform 42

42 Cloud 43

43 44

44 45

45 Tuoterungot, etuja: kirjaa tähän 46

46 Tuoterungot, ongelmat: kirjaa tähän 47

47 Tuoterunkojen etuja Etuja: Pitkälle viety koodin, osaamisen uudelleenkäyttö Erikoisosaamisen tarve vähenee tuotteiden toteuttajilla Tuoterunko voi hoitaa laitteistoläheistä, tietokantaspesifistä, vaativaa laskentaa jne. (sovellusten toteuttajissa esim. UI-osaajia jne.) Nopeutunut tuotesykli Tuottavuuden kasvu pitkällä tähtäyksellä Tuotteiden standardointi Kehitysprosessien ja työkalujen standardointi Laadun paraneminen Tukee nopeaa protoilua (jos tuoterunko olemassa) 48

48 Potentiaalisia ongelmia Henkilökunnan vaihtuvuus: motivointi, asiantuntemus, gurukeskeisyys Jäykistää kehitystä Konfliktit alusta vastaan tuotteet (kattavuus, aikataulut, resurssit ym.) Konfliktit tuotteiden haluttujen ominaisuuksien välillä Tuotantoviive: ensimmäinen tuote kestää kauan Testaus: miten testataan tuoterunko? Tuoterungon fokuksen katoaminen Kvartaaliekonomia 49

49 Kysyttävää?