Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Osaamistavoitteet Opiskelija osaa suunnitella komponenttipohjaisen ohjelmiston. Opiskelija osaa kuvata ohjelmistoarkkitehtuurin ja soveltaa ohjelmiston arkkitehtuurin mallintamisessa UML-notaatiota. Opiskelija ymmärtää ohjelmistoarkkitehtuurien yleisten ratkaisumallien ideat ja osaa soveltaa niitä ohjelmistojen suunnittelussa. Opiskelija ymmärtää tuoterunkoarkkitehtuurien peruskäsitteet ja osaa suunnitella tuoterunkoarkkitehtuurin. Opiskelija osaa suorittaa ja raportoida ohjelmistoarkkitehtuurin arvioinnin. 2 1
Mitä olisi pitänyt oppia? Sisältö Ydinaines Täydentävä tietämys Erityistietämys 1 Arkkitehtuurien kuvaus UML-mallintaminen arkkitehtuurin kannalta 2 Arkkitehtuureihin liittyvät standardiratkaisut 3 Tuoterunkoarkkitehtuurit ja ohjelmistoalustat Suunnittelumallit Arkkitehtuurityylit Kehysarkkitehtuurit Sulautettujen järjestelmien suunnittelumallit Integrointi Tuoterunkoarkkitehtuuri en kuvaus 4 Arkkitehtuurien arviointimenetelmät ATAM-menetelmän suoritus 3 Mitä olisi pitänyt oppia? Kyky ajatella itsenäisesti ja kriittisesti 4 2
Kurssiyhteenveto Arkkitehtuurien kuvaus Perusmekanismit Standardiratkaisut Tuoterunkoarkkitehtuurit Arkkitehtuurien arviointi 5 Arkkitehtuurin kuvaukseen liittyvät käsitteet (IEEE 1471-2000) Environment Mission fulfills 1..* System has an identifies Architecture 1 described by Architectural description provides selects Rationale has 1..* 1..* Stakeholder 1..* 1..* has 1..* is addressed to 1..* organized by View conforms to Concern Viewpoint 1..* 6 3
Arkkitehtuurinäkymät Näkymä Näkymä Arkkitehtuurikuvaus Näkymä Näkymä kuvaa tietyn arkkitehtuuriin liittyvän asian tietyllä abstraktiotasolla Näkymien kuvaamat asiat ovat osittain päällekkäisiä järjestelmän kannalta Toimiva järjestelmä 7 Skenaarionäkymä: käyttötapauskaavio CarRentalSystem" Reserve vehicle Deliver vehicle Client Return vehicle Clerk <<include>> Service Service 8 4
Tarkennettu skenaarionäkymä: aktiviteettikaavio Client Car request Clerk Make reservation :Bill [open] Make bill :Bill [paid] Pay Prepare car Take car Registrate renting 9 Looginen näkymä (rakenne): luokkakaavio Transaction kind info setkind setinfo TransactionManager * 1 handletransaction 1 1 Database * Store service information creates uses RentManager reserve(car,client) release(car) engage(car) return(car) update() 1 manages * RentableItem rents setreturned setreserved setactive setid Car regnumber setreturned * RentableStorage PrivateClient id name address creditcard 1 0..1 Feature code description Client creates <<interface>> LocationControl getpos(car) * ItemManager controller setcar(car) start() stop() reserve() release() engage() return() lost() recover() Garage GPSService 10 5
Looginen näkymä (käyttäytyminen): sekvenssikaavio UI : RentManager acar: Car : Garage return(acar) setreturned store(acar) update 11 Looginen näkymä (käyttäytyminen): yhteistoimintakaavio 1.1: setreturned acar: Car UI 1: return(acar) : RentManager 1.3: update() 1.2: store(acar) : Garage 12 6
Prosessinäkymä: tilakaavio For a ItemManager object:" Lost" do/announcement after(1 day) Vulnerable" do/warning recover Service" do/makereport" lost return /" stoptiming" recover [suspect location] Active" after(1 hour) LocCheck" do/check location release engage/starttiming" Available" Reserved" reserve" 13 Fyysinen näkymä: sijoittelukaavio SiteWorkStation: Client" : GUI" : Rent" Manager" : Item" Manager" <<Corba>> VehicleServer: Server" : Transaction" Manager" : Database " 14 7
Kehitysnäkymä: pakkauskaavio Items" +Car" +Feature" Clients" +PrivateClient" +Company" Core" +RentManager" +CarManager" +Rentable" <<import>>" +RentableStorage" +LocationControl" +Client" <<import>>" <<import>>" DB" +Transaction" +TransactionManager" +Database" Storage" <<import>>" +Garage" <<import>>" GPS" +GPSService" 15 Muunneltavuusnäkymä: luokkakaavio feature Adding new item feature palette FeaturePalette Feature code description seticon(featureicon) price(): Integer * 1 FeatureIcon draw iconinterface initializer initcode add(feature) NewFeature price(): Integer myfeature myicon NewFeatureIcon draw initialize() Main... f = new NewFeature(...); fi = new FeatureIcon(...); f.seticon(fi); featurepalette.add(f);... 16 8
Arkkitehtuuridokumentin sisältö Seuraavat asiat (soveltuvin osin) tulisi ilmetä dokumentista: Identifiointi: mistä organisaatiosta, järjestelmästä ja dokumentista on kyse Konteksti: liiketoimintatavoitteet, sidosryhmät, kehitysympäristö Vaatimukset: arkkitehtuurin kannalta merkittävät vaatimukset Rajoitteet Toimintaympäristö Näkymät: kuvauksen ydin valittujen näkökulmien mukaiset näkymät, mallit Tärkeimmät arkkitehtuuriratkaisut ja niiden perustelut Analyysi: arkkitehtuurin arvioinnin tulokset 17 Sovellusten koostaminen komponenteista Visio: sovellus kootaan olemassaolevista komponenteista Työkaluja: skriptit, XML, visuaaliset koostamistyökalut 9.2.2013 18 9
3.2 Mikä on ohjelmistokomponentti? Komponentti = itsenäinen ohjelmistoyksikkö, joka tarjoaa palveluja hyvin määritellyn rajapinnan kautta Szyperski: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. 9.2.2013 19 3.3 Komponentit ohjelmistoyksikköinä Arkkitehtuurin perusyksikkö: Toiminnallisuuden yksikkö mikä osa vastaa tietystä toiminnallisuudesta? Uudelleenkäytön yksikkö mikä osat ovat yhteisiä eri tuotteissa? Tuotekonfiguraation yksikkö mitä osia kuuluu tuotteeseen? Käyttöönoton yksikkö mitkä osat voidaan ottaa erikseen käyttöön? Muuntelun yksikkö mitkä osat voidaan vaihtaa toisiksi? Ulkopuolisen kehityksen yksikkö mitkä osat voidaan saada muualta? Työnjaon yksikkö mitkä osat tuotetaan tietyillä henkilöillä/yksiköillä? 9.2.2013 20 10
Tarjotut ja vaaditut rajapinnat UML 2.x:ssa PowerSource tarjottu rajapinta Car Engine PowerSource vaadittu rajapinta Car PowerSource Engine 9.2.2013 21 Rajapintojen sopimuspohjainen määrittely tuloehto (esiehto): täytyy päteä kun palvelua kutsutaan palvelun rajapinta design-by-contract Palvelun pyytäjä Palvelun tarjoaja" Tulo- ja jättöehdot määrittelevät palvelun merkityksen sallivat osapuolten vaihtamisen, kunhan tulo- ja jättöehdot pysyvät voimassa määräävät tarkistusvastuun osapuolten välillä palvelun tarjoaja joko täyttää sopimuksen tai aiheuttaa poikkeuksen jättöehto (jälkiehto): täytyy päteä kun palvelu on suoritettu, olettaen että tuloehdot olivat voimassa kun palvelu aloitettiin 9.2.2013 22 11
3.6 Komponenttien räätälöinti komponentin (alku)tilan muuttaminen vaadittujen rajapintojen toteutuksen antaminen tai muuttaminen aliluokittaminen 9.2.2013 23 5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Esimerkki: Rekursiokooste Antisuunnittelumallit Suunnittelumallit ja UML Mallikielet Suunnittelumallit eivät ole... Yhteenveto http://www.enteract.com/~bradapp/docs/patterns-intro.html http://www.hillside.net/patterns/ 24 12
Esimerkki: Mallikieli koneenohjausjärjestelmille 25 Toteutusriippuvuuksien poistaminen rajapinnoilla A B A ei tunne A IB B miten mitä 26 13
Komponenttien vuorovaikutuksen hallinta Joukko keskenään kommunikoivia komponentteja Ongelmia: komponenttien väliset riippuvuudet mutkikkaita ja vaikeita hallita jos jokin yhteistoiminta halutaan muuttaa, joudutaan jokaista osallistujaa muuttamaan komponentteja ei voi käyttää toisessa yhteydessä 27 Komponenttien vuorovaikutuksen hallinta Joukko keskenään kommunikoivia komponentteja Ongelmia: komponenttien väliset riippuvuudet mutkikkaita ja vaikeita hallita jos jokin yhteistoiminta halutaan muuttaa, joudutaan jokaista osallistujaa muuttamaan komponentteja ei voi käyttää toisessa yhteydessä 28 14
Riippuvuuksien poistaminen takaisinkutsuilla Takaisinkutsu Palvelun tarjoajalta sen pyytäjälle kesken palvelun tuleva kutsu. Tekniikka, jonka avulla palvelun pyytäjä voi saada kontrollin kesken palvelun suorituksen. Tavallisesti palvelu kuuluu johonkin yleiskäyttöiseen kirjastoon, joka ei saa tulla riippuvaksi kirjastoa käyttävistä sovelluksista. Takaisinkutsu mahdollistaa sovelluskohtaisen räätälöinnin yleiskäyttöisille palveluille ilman, että ne tulevat riippuviksi sovelluksista. 29 Riippuvuuksien vähentäminen tapahtumien avulla Tapahtuma on ohjelman ajoaikainen tietoalkio, jonka synnyttää jokin komponentti, jonka syntymiseen reagoi yksi tai useampi komponentti ja joka häviää sen jälkeen kun ei ole olemassa enää komponenttia, jonka tulisi reagoida sen syntymiseen. Tapahtuman synnyttäjä ei tunne tapahtuman syntymään reagoivia yksiköitä 30 15
Rajapinnat vs. viestit Komponentit, Asiakas-palvelin, Web palvelut (SOA), C++, Java kutsuu func A(X ) Rajapinta toteuttaa Palvelun tarjoaja Palvelun pyytäjä kirjoittaa Viestinvälitysarkkitehtuurit, palveluväylät (ESB), Smalltalk Viesti ACTION = A PAR1 = X Viestin välittäjä lukee ja toteuttaa Palvelun tarjoaja Rajapinta kertoo mitä tehdään ja millä tiedolla, viesti voi kertoa mitä tahansa (mitä tehdään, kuka tekee, millä tiedolla). 31 Sovitin (Adapter) suunnittelumalli Client AbstractServices request() ConcreteServices concrequest()... adaptee.concrequest() Adapter request() adaptee Server 32 16
Luontiriippuvuuksien vähentäminen tehtaalla FactoryRegistry register(factory) AppInit Factory create(): Product AppFactory <<create>> (alustus) Platform <<create>> (käyttö) Product service AppProduct 33 Mitä ovat arkkitehtuurityylit? Arkkitehtuurityyli = yleinen malli, joka kertoo miten järjestelmä organisoidaan ylimmällä abstraktiotasolla, määräten järjestelmän yleisen teknisen luonteen Arkkitehtuurityylit eivät sulje toisiaan pois! Kysymyksiä, jotka voivat johtaa arkkitehtuurityylin valintaan: - Koostuuko järjestelmä komponenteista, jotka ovat selvästi eri käsitetasoilla? - Onko järjestelmän päätarkoitus jalostaa tietoa? - Jaetaanko järjestelmässä jotain resurssia tai tietoa erillisille sovelluksille? - Koostuuko järjestelmä joukosta komponentteja, jotka kommunikoivat keskenään etukäteen tuntemattomilla tavoilla? Ovatko komponentit usein vaihtuvia? 34 17
Kerrosarkkitehtuurien edut ja ongelmat Etuja Melkein aina sovellettavissa Tukee järjestelmän ymmärtämistä ja hallintaa Vähentää riippuvuuksia (ylläpidettävyys, muunneltavuus) Helppo liittää yrityksen organisaatioon (Conway) Tukee uudelleenkäyttöä (tuoterunkoarkkitehtuurin pohjana) Ongelmia Suorituskyky voi heikentyä (epäsuoruus) Saattaa johtaa tarpeettomaan/moninkertaiseen laskentaan Poikkeusten käsittely 35 Tietovuoarkkitehtuurien edut ja ongelmat Etuja: Mutkikas tiedon käsittelyprosessi voidaan jakaa helpommin hallittaviin palasiin Tukee uudelleenkäyttöä: prosessointiyksiköitä voidaan kombinoida eri tavoin Tukee ylläpitoa: prosessointiyksikköä voidaan helposti muuttaa Tukee rinnakkaisuutta Ongelmia: Ei sovi interaktiivisille järjestelmille Tiedon tulkinnasta tulee suorituskykyrasitetta Virhetilanteiden käsittely voi olla vaikeaa 36 18
Asiakas-palvelin arkkitehtuurien edut ja ongelmat Etuja Helpottaa yhteisen resurssin hallintaa (esim. tietoturva) Helpottaa ylläpitoa ja muunneltavuutta (esim. palvelimen vaihto) Hyvä teknologinen tuki Ongelmia Verkkoliikenteestä johtuvat suorituskykyongelmat Palvelinkeskeisyys: kriittisen palvelimen vikaantuminen Poikkeusten käsittely 37 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 38 19
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 39 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 40 20
10. Muunneltavuuden hallinta: variaatiopisteet Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat, jotka auttavat kuvaamaan, toteuttamaan ja hyödyntämään ohjelmistotuotteiden variaatiota. 41 Variaatiopisteet: Määrittely ja sitominen Määrittelyvaihe Sitomisvaihe [Michel Jaring 2005] 42 21
Variaation kuvaaminen vaatimusmäärittelyssä: piirremallit Käytetään UML-profiilia (ei standardi) <<context>> Handheld Device SDK variability <<mandatory>> Network channels { BindingTime = runtime } <<mandatory>> Display orientation { BindingTime = development } <<mandatory>> Control method { BindingTime = development } <<optional>> GPS support { BindingTime = development } {xor} {xor} <<alternative>> WLAN <<alternative>> GSM Data <<mandatory>> Command buttons Yhdistelysääntöjen määritys: OCL <<alternative>> Horizontal <<alternative>> Pen Voidaan käyttää myös lukumääräsuhteita <<alternative>> GPRS <<alternative>> Vertical <<alternative>> Keyboard 43 Muunneltavuus arkkitehtuurityyleissä Tyyli Tuotteissa vaihtuvat Tuotteiden yhteiset osat Kerros Kerrokset Kerrosrajapinnat, alemmat kerrokset Tietovuo Prosessointiyksiköt Tietoformaatti, perusyksiköt Asiakas-palvelin Viestinvälitys Asiakkaat, palvelimen toteutus Kommunikoivat komponentit, viestit Asiakkaiden transaktiorajapinta Viestinvälitysinfra, viestiformaatti MVC Tulkki Näkymä- ja ohjainkomponentit Suoritusalusta, kielen osat Malli Kielen kääntäjä ja tulkki 44 22
Variaatiopisteet yksityiskohtaisen suunnittelun tasolla Alemman tason suunnittelumallit (esim. Template Method, Strategy) Periyttäminen Takaisinkutsut 45 Template Method ja Strategy 46 23
Variaatiopisteiden sitominen järjestelmän asennuksessa ja käytössä Määritellään suunnittelutasolla Asennusparametrit Käyttäjän asetukset GUI räätälöinti Adaptoituvat käyttöliittymät Tulkattava skripti 47 Kehys erikoistetaan toimivaksi tuotteeksi Kehys Sovelluskohtainen koodi kontrolli Erikoistamisrajapinta 48 24
Sovelluskehys vs. perinteinen ohjelmakirjasto: Hollywoodperiaate Aliluokkia, komponentteja Sovelluskohtainen Sovellus Uudelleenkäytettävä Sovelluskehys Aliohjelmia, luokkia, moduuleita Hollywood-periaate: Älä soita meille, me soitetaan teille 49 <<framework>> SimulationFW Muunneltava kehys <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() * World getsize(): int add(creature) remove(creature) show() simulate(int, CreatureFactory) <<interface>> CreatureFactory 1 createcreature(): Creature DefaultCreature <<create>> DefaultCreatureFactory xcoord ycoord age setmyworld(world)... die() <<create>> createcreature(): Creature EatingCreature energy interact(creature) SimulationApp main() <<create>> <<create>> EatingCreatureFactory createcreature(): Creature 50 25
<<framework>> SimulationFW DefaultCreature xcoord ycoord age <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() setmyworld(world)... die() * Koottava kehys World getsize(): int add(creature) remove(creature) show() simulate(int,creaturefactory) <<create>> EatingCreature energy interact(creature) <<create>> <<create>> <<interface>> CreatureFactory 1 createcreature(): Creature DefaultCreatureFactory createcreature(): Creature EatingCreatureFactory createcreature(): Creature SimulationApp <<create>> main() 51 <<framework>> SimulationFW <<interface>> Creature setmyworld(world) show() getx(): int gety(): int move() interact(creature) growold() die() * Plug-in kehys World getsize(): int add(creature) remove(creature) show() simulate(int,creaturefactory) 1 PluginLoader <<interface>> CreatureFactory createcreature(): Creature load() <<load>> <<plugin>> EatingApplication EatingCreature energy interact(creature) SimulationApp EatingCreatureFactory main() createcreature(): Creature <<create>> 52 26
Kehykset ja suunnittelumallit Suunnittelumalleilla (GoF) voidaan lisätä järjestelmän joustavuutta sekä tavallisissa sovelluksissa (ylläpidettävyys, siirrettävyys) että kehyksissä (uudelleenkäytettävyys) Hyvin suunniteltu oliosovellus voidaan ymmärtää usein (implisiittisen) kehyksen erikoistuksena. 53 Tyypillisiä kehyksissä käytettyjä GoF-suunnittelumalleja Operaatiorunko (Template Method) Strategia (Strategy) Kuorruttaja (Decorator) Tehtaat (Abstract Factory, Factory Method) Tarkkailija (Observer)... 54 27
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 55 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ä 56 28
Liiketoimintanäkökulma Kumulatiivinen kustannus 4C 3C takaisinmaksu perinteinen tuoterunko 2C 1C alustan rakentaminen 0 12 3 4 Sovellusten lukumäärä 57 Tuoterunkojen etuja ja ongelmia Etuja: Pitkälle viety koodin, osaamisen uudelleenkäyttö Nopeutunut tuotesykli Tuottavuuden kasvu pitkällä tähtäyksellä Tuotteiden standardointi Kehitysprosessien ja työkalujen standardointi Laadun paraneminen Tukee nopeaa protoilua 58 29
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 59 30