ohjelmistoarkkitehtuurit kevät 2014ohar/luennot_materiaali/ohar11 tuoterungot...perustuen (tetris,...

Ohjelmistoarkkitehtuurit

Kevät 2014

Samuel Lahtinen

(Johannes Koskinen)

http://www.cs.tut.fi/~ohar/

27.3.2014 Ohjelmistoarkkitehtuurit 2014 1

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?

– http://www.tut.fi/fi/tietoa-yliopistosta/toihin-

ttylle/index.htm


http://www.tut.fi/fi/tietoa-yliopistosta/toihin-ttylle/index.htm






Presemo-testi

• m31.screen.io/ohar

• Tai kurssin kotisivujen kautta:


Aiemmin käytyä

• Muunneltavuuden hallintaa

• ==Miten mahdollistaa tiettyjen asioiden muuntelu,

ylläpito, päivittäminen ilman hirveää tuskaa

– (Huono autovertaus…)


11. Tuoterunkoarkkitehtuurit

• Johdanto

• Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen:

liiketoiminta, organisaatio, prosessi, tekninen

• Tuoterunkojen etuja ja ongelmia

5 27.3.2014 Ohjelmistoarkkitehtuurit 2014

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


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


Tuoterunko = yhteiseen arkkitehtuuriin ja

alustaan perustuva ohjelmistojen

uudelleenkäyttö

• Suunniteltu ja ylhäältä-alas

• Tuoterunkoarkkitehtuurit (Product-line Architectures):

– http://www.sei.cmu.edu/productlines/

– http://www.sei.cmu.edu/architecture/essays.html#j

azayeri

– Software Product Line Engineering: Foundations,

Principles and Techniques:Klaus Pohl, Günter

Böckle, Frank J. van der Linden (2005) – http://www.computerscience.nl/wiki/pub/MethodEngineering/TowardsMulti-

ViewFBC20122013/Pohl_et_al%282005%29.pdf


http://www.sei.cmu.edu/productlines/

http://www.sei.cmu.edu/productlines/

http://www.sei.cmu.edu/architecture/essays.html#jazayeri




http://www.computerscience.nl/wiki/pub/MethodEngineering/TowardsMulti-ViewFBC20122013/Pohl_et_al(2005).pdf




Anna esimerkkejä

tuoterunkoajatteluun sopivista

sovellusalueista

• Uta, Vaasa, Turku: Presemo (m31.screen.io/ohar)

• TTY: huutelu tai oma Presemo-kohta

• 3min mietintäaikaa


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


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?



12

Sovellusten lukumäärä

0 1 2 3 4

tuoterunko takaisinmaksu

1C

2C

3C

4C

alustan rakentaminen

perinteinen

27.3.2014 Ohjelmistoarkkitehtuurit 2014


13

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), 85-88.


Esimerkki (”oikea”)

14

Sovellusalue: videopelit

0 100 800 700 600 500 400 300 200 900

työtuntia

Perinteinen

Kehykseen perustuva

1. peli 2. peli 3. peli

Kehyksen rakentaminen + koulutus

Suorituskyky:

aika +70%

tila +200%

Santelices R.A., Nussbaum M.: A framework for the development of videogames.

Software Practice & Experience 31 (2001), 1091-1107.


pulmapelitehdas…

Yritys pohtii mahdollisuuksia lähteä tuottamaan kännykkään pulmapelituoterunkoalustaan

perustuen (Tetris, palluroiden, värien jne. yhdistelypelit)

Oletetaan, että pulmapelisovelluksen toteuttamisen keskihinta on 100.000e, ja sovelluksen

kehittäminen kestää 6kk (ilman tuotealustaa). Millä edellytyksillä yrityksen kannattaa investoida

tuotealustaan, jos tuotealustan perustamiskustannukset ovat 250.000e ja toteutustyöhön kuluu

12kk, ja tämän jälkeen pelisovelluksen hinta on vain 25.000e, 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 10.000 e?

Tarkastele asiaa eri puolilta yrityksen johdon kannalta, ottaen huomioon mahdolliset

liiketoimintatavoitteet, henkilöresurssien käyttö, reagointikyky markkinoihin ym.


Uudelleenkäytön kypsyystasot

16

Kypsyystaso Konfiguroitava tuoterunko

(automaattinen tuki tuotteen rakentamiselle)

Yhteinen arkkitehtuuri, variaatiopisteet

(tuoterunko)

Yhteinen alusta, yhteistä toiminnallisuutta

Standardisoitu infrastruktuuri

(yhteinen OS, DB, GUI jne.)

Riippumattomat tuotteet


Hierarkkinen tuoterunko

17

Jan Bosch


Organisaation kypsyys

suhteessa arkkitehtuuriin

19

Arkkitehtuuri

selittää

järjestelmää

Arkkitehtuuri

ohjaa

järjestelmän

rakentamista

Arkkitehtuuri

mahdollistaa

erilaisten järjestelmien

rakentamisen (tuoterunko)

organisaation kypsyys


Kysyttävää?

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)


Tuoterunkoprosessi

22

Vaatimus-

määrittely Alustan

suunnittelu

Sovellusalueen

käsitemalli

Alustan

toteutus

Muunneltavuus-

vaatimukset,

piirremalli

Tuoterunko-

arkkitehtuuri

Yhteiset

vaatimukset

Alustakehitysprosessi

Alusta

Tuote-

vaatimukset Tuoteen

toteutus

Tuoterunko-

rajapinta

Tuote-

kohtainen

koodi

Tuotekehitysprosessi

Vaatimus-

määrittely

Variaationhallinta

Arviointi

sisältyy


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


Tuoterunko-organisaatio

24

Asiakas

Tuoteryhmät Tuoterunko

ryhmä

Johto

Asiakkaan

tarpeet

Tuoterungon

mahdollisuudet Tuotteen

ominaisuudet

Komponentit

Päivitykset

Vaatimukset

Mahdollisuudet

Tuotteet

Tuoterungon mahdollisuudet

Vaatimukset

Palaute

Tuotteen ymmärrys

Asiakkaan tarpeiden ymmärrys

Komponenttipohjainen kehitys

Räätälöintikyky

Toteutustekniikoiden tuntemus

Sovellusalueen ymmärrys

Arkkitehtuuriosaaminen

Abstrahointikyky

Teknologiatuntemus

Kommunikaatiokyvyt

Markkinointi

Tuoterungon ymmärtäminen,

sitoutuminen, puolustaminen

(”Champion”)


Tuoterunkoja tukevia

teknologioita

• Komponenttiteknologiat

• Olioteknologiat, kehykset

• Mallintamisteknologiat, UML

• Sovellussuuntautuneet kielet, XML

• Tekstuaalisten ja visuaalisten kielten

rakentamisympäristöt


Tuoterunkoarkkitehtuurit vs.

DSL

26

Vaatimukset Kääntäjä Ajettava

sovellus

Koodi



DSL

27

Koodi DSL

koodi

DSL kehitin

DSL =

Domain-

Specific

Language


sovellus

Koodi



DSL

28

Koodi

tuoterunkorajapinta

Alusta

Yhteinen arkkitehtuuri ja

sovellusalueen tuki

Koodi DSL

koodi

DSL kehitin

DSL =

Domain-

Specific

Language


sovellus

Koodi



DSL

29

Koodi

tuoterunkorajapinta

Alusta

Yhteinen arkkitehtuuri ja

sovellusalueen tuki

Koodi DSL

koodi

DSL kehitin

DSL =

Domain-

Specific

Language


sovellus

Koodi


Kysyttävää?

Kerrostyyli

tuoterunkoarkkitehtuureille

31

Sovellusalusta

Arkkitehtuurialusta

Resurssialusta

So

ve

llus

So

ve

llus

So

ve

llus

So

ve

llus

So

ve

llus

Sovellu

s

So

ve

llus

So

ve

llus


Esimerkki: EJB-pohjainen

tuoterunko

32

Pankkisovellustuki

EJB: hajautettu asiakas-palvelintuki

Tietokantapalvelut, tietoliikennepalvelut, KJ

Talletustilien hallintajärjestelmä Tuote

Sovellus-

alusta

Arkkitehtuuri-

alusta

Resurssi-

alusta

vrt. yleinen liiketoimintajärjestelmien kerrosarkkitehtuuri


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.


34

MessageDispatcherIF

send(Msg)

register(MsgType,Component)

Component

Msg

receive(Msg)

type(): MsgType

XMLMsg

GSMComp BrakeState

DBAccess BrakeController

recordUsage

checkCondition

register(View)

getState()

setState()

handleEvent(Event)

BrakeViewIF update()

CANBus

CANFilter

Message

Dispatcher

sendReport

Brake-

View

BrakeModelIF


Harjoitus

35

Sovellus

Sovellus-

alusta

Arkkitehtuuri-

alusta

Resurssi-

alusta


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


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?


Esimerkkejä tuoterungoista

• Kännykkäalustat

• Vakuutusjärjestelmäalustat

• Pankkijärjestelmäalustat

• Tietokone- ja kännykkäpelialustat

• Koneenohjausjärjestelmäalustat

• …


ISA arkkitehtuuri (Nokia)

39

Veijola 1999


Tuoteperhe-esimerkki

(Vignet terveyspalveluita)


http://www.vignetcorp.com/platform-approach

Ohjelmistorunko ja

laitteet


42

S60 Product Platform


Cloud


http://blogs.msdn.com/


http://www.ondemandbeat.com


http://www.calsoftinc.com/

Tuoterungot, etuja: kirjaa

tähän


Tuoterungot, ongelmat: kirjaa

tähän


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)


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


Kysyttävää?

ohjelmistoarkkitehtuurit kevät 2014ohar/luennot_materiaali/ohar11 tuoterungot...perustuen (tetris,...

Documents